Thread: Stack Smashing Detected When Executing initdb
Hi everyone,
Today I tried to build the latest devel version of PostgreSQL(commit 70a845c04a47645b58f8276a6b3ab201ea8ec426). The compilation was successful, but when I ran initdb an error occured:
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /usr/local/pgsql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Asia/Shanghai
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... *** stack smashing detected ***: terminated
Aborted (core dumped)
child process exited with exit code 134
initdb: removing contents of data directory "/usr/local/pgsql/data"
After searching for solutions on the Internet, I disabled the stack smashing protector by performing
./configure CC='clang -fno-stack-protector'
However, the problem still exists. Is there anyone else having this issue?
Regards,
Haorong Xu
Haorong Xu
Hi Xu
To pinpoint the issue, please use gdb debugger to get the backtrace to exactly find out where the error is occurring and you can then do the required setups.
For Reference : https://stackoverflow.com/questions/50093327/how-do-i-solve-postgresql-aborted-core-dumped-error
Thanks
Kashif Zeeshan
On Sun, Jun 23, 2024 at 12:19 PM Xu Haorong <db_haorong@outlook.com> wrote:
Hi everyone,Today I tried to build the latest devel version of PostgreSQL(commit 70a845c04a47645b58f8276a6b3ab201ea8ec426). The compilation was successful, but when I ran initdb an error occured:/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/dataThe files belonging to this database system will be owned by user "postgres".This user must also own the server process.The database cluster will be initialized with locale "en_US.UTF-8".The default database encoding has accordingly been set to "UTF8".The default text search configuration will be set to "english".Data page checksums are disabled.fixing permissions on existing directory /usr/local/pgsql/data ... okcreating subdirectories ... okselecting dynamic shared memory implementation ... posixselecting default "max_connections" ... 100selecting default "shared_buffers" ... 128MBselecting default time zone ... Asia/Shanghaicreating configuration files ... okrunning bootstrap script ... okperforming post-bootstrap initialization ... *** stack smashing detected ***: terminatedAborted (core dumped)child process exited with exit code 134initdb: removing contents of data directory "/usr/local/pgsql/data"After searching for solutions on the Internet, I disabled the stack smashing protector by performing./configure CC='clang -fno-stack-protector'However, the problem still exists. Is there anyone else having this issue?Regards,
Haorong Xu
Hi Xu
You need to enable some settings for the code dump to generated.
For the settings you can use following link.
Regards
Kashif Zeeshan
On Sun, Jun 23, 2024 at 7:07 PM Xu Haorong <db_haorong@outlook.com> wrote:
Hi Zeeshan,Thank you for helping me. I tried to analyze the core dump file, but unfortunately it didn't seem to have generated one. Therefore I ran initdb with gdb, which produced following output:Program received signal SIGPIPE, Broken pipe.0x00007ffff791c574 in __GI___libc_write (fd=4, buf=0x555555636a60, nbytes=64) at ../sysdeps/unix/sysv/linux/write.c:26warning: 26 ../sysdeps/unix/sysv/linux/write.c: No such file or directoryThe error message clearly indicates that something like write.c is missing, which is included in GNU C Library. However, I found that I've already installed it on my computer. It also confuses me that there was no core dump file at all, since initdb says "Aborted (core dumped)". I'd really appreciate if you can give me further information.Regards,Haorong Xu发件人: Kashif Zeeshan <kashi.zeeshan@gmail.com>
发送时间: 2024年6月23日 16:50
收件人: Xu Haorong <db_haorong@outlook.com>
抄送: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
主题: Re: Stack Smashing Detected When Executing initdbHi XuTo pinpoint the issue, please use gdb debugger to get the backtrace to exactly find out where the error is occurring and you can then do the required setups.For Reference : https://stackoverflow.com/questions/50093327/how-do-i-solve-postgresql-aborted-core-dumped-errorThanksKashif ZeeshanOn Sun, Jun 23, 2024 at 12:19 PM Xu Haorong <db_haorong@outlook.com> wrote:Hi everyone,Today I tried to build the latest devel version of PostgreSQL(commit 70a845c04a47645b58f8276a6b3ab201ea8ec426). The compilation was successful, but when I ran initdb an error occured:/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/dataThe files belonging to this database system will be owned by user "postgres".This user must also own the server process.The database cluster will be initialized with locale "en_US.UTF-8".The default database encoding has accordingly been set to "UTF8".The default text search configuration will be set to "english".Data page checksums are disabled.fixing permissions on existing directory /usr/local/pgsql/data ... okcreating subdirectories ... okselecting dynamic shared memory implementation ... posixselecting default "max_connections" ... 100selecting default "shared_buffers" ... 128MBselecting default time zone ... Asia/Shanghaicreating configuration files ... okrunning bootstrap script ... okperforming post-bootstrap initialization ... *** stack smashing detected ***: terminatedAborted (core dumped)child process exited with exit code 134initdb: removing contents of data directory "/usr/local/pgsql/data"After searching for solutions on the Internet, I disabled the stack smashing protector by performing./configure CC='clang -fno-stack-protector'However, the problem still exists. Is there anyone else having this issue?Regards,
Haorong Xu
Hi Zeeshan,
Thank you for replying me. I'm aware that core dump files are not generated by default, so I did change my settings to allow them to be generated. But initdb still doesn't generate any core dump file, that's what makes this issue especially unusual.
Regards,
Haorong Xu
发件人: Kashif Zeeshan <kashi.zeeshan@gmail.com>
发送时间: 2024年6月23日 22:13
收件人: Xu Haorong <db_haorong@outlook.com>; Postgres General <pgsql-general@postgresql.org>
主题: Re: Stack Smashing Detected When Executing initdb
发送时间: 2024年6月23日 22:13
收件人: Xu Haorong <db_haorong@outlook.com>; Postgres General <pgsql-general@postgresql.org>
主题: Re: Stack Smashing Detected When Executing initdb
Hi Xu
You need to enable some settings for the code dump to generated.
For the settings you can use following link.
Regards
Kashif Zeeshan
On Sun, Jun 23, 2024 at 7:07 PM Xu Haorong <db_haorong@outlook.com> wrote:
Hi Zeeshan,Thank you for helping me. I tried to analyze the core dump file, but unfortunately it didn't seem to have generated one. Therefore I ran initdb with gdb, which produced following output:Program received signal SIGPIPE, Broken pipe.0x00007ffff791c574 in __GI___libc_write (fd=4, buf=0x555555636a60, nbytes=64) at ../sysdeps/unix/sysv/linux/write.c:26warning: 26 ../sysdeps/unix/sysv/linux/write.c: No such file or directoryThe error message clearly indicates that something like write.c is missing, which is included in GNU C Library. However, I found that I've already installed it on my computer. It also confuses me that there was no core dump file at all, since initdb says "Aborted (core dumped)". I'd really appreciate if you can give me further information.Regards,Haorong Xu发件人: Kashif Zeeshan <kashi.zeeshan@gmail.com>
发送时间: 2024年6月23日 16:50
收件人: Xu Haorong <db_haorong@outlook.com>
抄送: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
主题: Re: Stack Smashing Detected When Executing initdbHi XuTo pinpoint the issue, please use gdb debugger to get the backtrace to exactly find out where the error is occurring and you can then do the required setups.For Reference : https://stackoverflow.com/questions/50093327/how-do-i-solve-postgresql-aborted-core-dumped-errorThanksKashif ZeeshanOn Sun, Jun 23, 2024 at 12:19 PM Xu Haorong <db_haorong@outlook.com> wrote:Hi everyone,Today I tried to build the latest devel version of PostgreSQL(commit 70a845c04a47645b58f8276a6b3ab201ea8ec426). The compilation was successful, but when I ran initdb an error occured:/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/dataThe files belonging to this database system will be owned by user "postgres".This user must also own the server process.The database cluster will be initialized with locale "en_US.UTF-8".The default database encoding has accordingly been set to "UTF8".The default text search configuration will be set to "english".Data page checksums are disabled.fixing permissions on existing directory /usr/local/pgsql/data ... okcreating subdirectories ... okselecting dynamic shared memory implementation ... posixselecting default "max_connections" ... 100selecting default "shared_buffers" ... 128MBselecting default time zone ... Asia/Shanghaicreating configuration files ... okrunning bootstrap script ... okperforming post-bootstrap initialization ... *** stack smashing detected ***: terminatedAborted (core dumped)child process exited with exit code 134initdb: removing contents of data directory "/usr/local/pgsql/data"After searching for solutions on the Internet, I disabled the stack smashing protector by performing./configure CC='clang -fno-stack-protector'However, the problem still exists. Is there anyone else having this issue?Regards,
Haorong Xu
Xu Haorong <db_haorong@outlook.com> writes: > Today I tried to build the latest devel version of PostgreSQL(commit 70a845c04a47645b58f8276a6b3ab201ea8ec426). The compilationwas successful, but when I ran initdb an error occured: > performing post-bootstrap initialization ... *** stack smashing detected ***: terminated > Aborted (core dumped) > child process exited with exit code 134 No such problem is visible in our build farm [1], so what we have to figure out is how your machine is different from all of those. You've provided exactly zero context: * What platform is this on (be specific)? Is the system software up-to-date? * What C compiler are you using, and what version exactly? * What configure options did you use? regards, tom lane [1] https://buildfarm.postgresql.org/cgi-bin/show_status.pl
I wrote: > Xu Haorong <db_haorong@outlook.com> writes: >> performing post-bootstrap initialization ... *** stack smashing detected ***: terminated >> Aborted (core dumped) >> child process exited with exit code 134 > No such problem is visible in our build farm [1], so what we have to > figure out is how your machine is different from all of those. Also, before you spend a lot of time chasing this, make sure it's not a mirage. Reset your source tree fully with "git clean -dfxq" then configure, make, make install; then see if problem still exists. If it does, the PG community's accumulated wisdom about getting stack traces is here: https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend Note that the "child process exited" message you show implies that the failure was not in initdb itself, but in the single-user postgres backend process that it spawns. This means that any core file would have been dumped into the created data directory, so you would have to use initdb's --no-clean option to prevent it from being removed immediately. Also, if you are using a systemd-based Linux distribution, you may have to negotiate with systemd-coredump to get back any core dump at all. "man 5 core" can be helpful reading here (personally I just disable systemd-coredump per the directions shown there). regards, tom lane
Hi Lane,
Thank you for your advice. The problem did disappear after running git clean, and I'm sorry for not providing enough context at first.
Regards,
Haorong Xu
Thats great, it also gave us a learning opportunity as well.
On Mon, Jun 24, 2024 at 10:18 AM Xu Haorong <db_haorong@outlook.com> wrote:
Hi Lane,
Thank you for your advice. The problem did disappear after running git clean, and I'm sorry for not providing enough context at first.Regards,Haorong Xu