Lars Aksel Opsahl <Lars.Opsahl@nibio.no> writes:
> (gdb) bt
> #0 0x00007fa9c241e70f in raise () from /lib64/libc.so.6
> #1 0x00007fa9c2408b25 in abort () from /lib64/libc.so.6
> #2 0x00007fa9c2461897 in __libc_message () from /lib64/libc.so.6
> #3 0x00007fa9c2467fdc in malloc_printerr () from /lib64/libc.so.6
> #4 0x00007fa9c24698dc in _int_free () from /lib64/libc.so.6
> #5 0x00007f992fe099f9 in osgeo::proj::common::UnitOfMeasure::~UnitOfMeasure() () from /lib64/libproj.so.15
> #6 0x00007fa9c2420e9c in __run_exit_handlers () from /lib64/libc.so.6
> #7 0x00007fa9c2420fd0 in exit () from /lib64/libc.so.6
> #8 0x000000000075beb0 in proc_exit (code=code@entry=0) at ipc.c:152
> #9 0x000000000077fd21 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x182b6d8, dbname=<optimized out>,
username=<optimizedout>) at postgres.c:4455
> #10 0x00000000007085a1 in BackendRun (port=0x1819b90, port=0x1819b90) at postmaster.c:4448
> #11 BackendStartup (port=0x1819b90) at postmaster.c:4139
> #12 ServerLoop () at postmaster.c:1704
> #13 0x00000000007094d0 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x17e7800) at postmaster.c:1377
> #14 0x0000000000482c7e in main (argc=3, argv=0x17e7800) at main.c:228
OK, I'd say that definitely puts the bug outside of core Postgres.
It looks like proj has installed an atexit() handler that is trying
to free something that was already freed. This might be proj's
fault directly, or perhaps a caller did something wrong (a likely
bet, perhaps, is using palloc for something that proj expects to
survive till program exit).
Probably the next step is to take this to the postgis support lists
and see what they think about it.
regards, tom lane