You know, I should have been able to think of that:
njamd says:
(gdb) set env LD_PRELOAD=libnjamd.so
(gdb) set env NJAMD_CHK_FREE=error
(gdb) r test_bad.pgc
Starting program: /var/lib/pgsql/src/postgresql-8.0.0/src/interfaces/ecpg/preproc/ecpg test_bad.pgc
NJAMD/free: Double free of address 0x41454ff4
Program received signal SIGSEGV, Segmentation fault. 0x4010a671 in kill () from /lib/i686/libc.so.6 (gdb) bt #0 0x4010a671 in kill () from /lib/i686/libc.so.6 #1 0x4010a405 in raise () from /lib/i686/libc.so.6 #2 0x4001f867 in __nj_underflow_free () from /usr/lib/libnjamd.so #3 0x4001fe93 in __nj_overflow_free () from /usr/lib/libnjamd.so #4 0x40021e87 in free () from /usr/lib/libnjamd.so #5 0x0805755f in remove_typedefs (brace_level=1073902784) at variable.c:271 #6 0x08049e02 in yyparse () at preproc.y:610 #7 0x08055db0 in main (argc=2, argv=0xbfffe254) at ecpg.c:424 #8 0x400f7a67 in __libc_start_main () from /lib/i686/libc.so.6
Tom Lane wrote:
Edmund Bacon <[EMAIL PROTECTED]> writes:
According to the backtrace, it appears to be dieing in malloc.
That's consistent with the idea that the multiple free is the source of trouble --- multiple free() could corrupt malloc's private data structures to the point of causing a crash in a later malloc call.
The least painful way of locating the problem would be to relink ecpg with a debugging malloc package, which could tell you exactly where the bad free() call is. You'd probably want to rebuild with --enable-debug too.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
-- Edmund Bacon <[EMAIL PROTECTED]>
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
