=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> One of the postgres processes in our production environment crashed with the
> following backtrace:
> (gdb) bt
> #0 thrkill () at -:3
> #1 0x000004a14ca47fbe in _libc_abort () at
> /usr/src/lib/libc/stdlib/abort.c:51
> #2 0x000004a14c9fd029 in wrterror (d=Variable "d" is not available.
> ) at /usr/src/lib/libc/stdlib/malloc.c:288
> #3 0x000004a14c9fd34f in ofree (argpool=Variable "argpool" is not
> available.
> ) at /usr/src/lib/libc/stdlib/malloc.c:1298
> #4 0x000004a14c9fd109 in free (ptr=0x4a115aec398) at
> /usr/src/lib/libc/stdlib/malloc.c:1416
> #5 0x000004a09a7301e8 in pg_fe_scram_free () from
> /usr/local/lib/libpq.so.6.10
> #6 0x000004a09a73561f in pqPacketSend () from
> /usr/local/lib/libpq.so.6.10
> #7 0x000004a09a731507 in PQfinish () from /usr/local/lib/libpq.so.6.10
> #8 0x000004a074dc5549 in GetConnection () from
> /usr/local/lib/postgresql/postgres_fdw.so
Hmm. Unfortunately, I don't think I believe this backtrace. For one
thing, there's no direct pathway from pqPacketSend to pg_fe_scram_free.
Also, if we ignore that and figure that somehow pg_fe_scram_free is
doing a duplicate free, it's still really hard to see how that would
happen.
Given that you didn't have debug symbols installed, it's not very
surprising for the trace to be misleading. Probably, what we're seeing
here is the nearest exported functions' names rather than where control
really went.
> If necessary I can build a debug version of PostgreSQL and try using that in
> production so I can get a better backtrace if it crashes again.
Please. I don't doubt that there's an issue here, but we're going to
need a higher-quality fix on where it is before we can do much.
regards, tom lane