Re: Stack Smashing Detected When Executing initdb
От | Tom Lane |
---|---|
Тема | Re: Stack Smashing Detected When Executing initdb |
Дата | |
Msg-id | 983895.1719167529@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Stack Smashing Detected When Executing initdb (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Stack Smashing Detected When Executing initdb
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: