Re: BUG #1440: ecpg seg faults

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 <ebacon@onesystem.com> 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 <ebacon@onesystem.com>