Re: free(): invalid pointer , when to dumping data to a new server

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)no>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: free(): invalid pointer , when to dumping data to a new server
Date: 2020-10-27 16:51:46
Message-ID: 1060532.1603817506@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)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(at)entry=0) at ipc.c:152
> #9 0x000000000077fd21 in PostgresMain (argc=<optimized out>, argv=argv(at)entry=0x182b6d8, dbname=<optimized out>, username=<optimized out>) 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(at)entry=3, argv=argv(at)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Alvaro Herrera 2020-10-27 17:36:18 Re: Odd pg dump error: cache lookup failure
Previous Message Lars Aksel Opsahl 2020-10-27 16:43:14 Re: free(): invalid pointer , when to dumping data to a new server