From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Xu Haorong <db_haorong(at)outlook(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Stack Smashing Detected When Executing initdb |
Date: | 2024-06-23 18:32:09 |
Message-ID: | 983895.1719167529@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I wrote:
> Xu Haorong <db_haorong(at)outlook(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | 毛毛 | 2024-06-23 18:43:06 | How to use createdb command with newly created user? |
Previous Message | Tom Lane | 2024-06-23 15:48:15 | Re: Stack Smashing Detected When Executing initdb |