Thread: Glibc error using ecpg

I just received this error from a program I'm testing with postgresql
9.  It is an operational program under 8.1.

 From the debug output, I think I am getting the following error on the
statement

   EXEC SQL CLOSE FROMID;

with the situation being that the cursor is on a result set with zero rows.

Here is the error info:

*** glibc detected *** mainprog: double free or corruption (!prev):
0x09ad5be8 ***
======= Backtrace: =========
/lib/i686/nosegneg/libc.so.6[0x6e51e5]
/lib/i686/nosegneg/libc.so.6(cfree+0x59)[0x6e5629]
mainprog[0x804ab53]
mainprog[0x804a375]
/lib/i686/nosegneg/libc.so.6(__libc_start_main+0xdc)[0x690e9c]
mainprog[0x8048a71]
======= Memory map: ========
00110000-0011d000 r-xp 00000000 fd:00 2019722
/usr/local/pgsql/lib/libpgtypes.so.3.1
0011d000-0011f000 rwxp 0000c000 fd:00 2019722
/usr/local/pgsql/lib/libpgtypes.so.3.1
00275000-00290000 r-xp 00000000 fd:00 2019039
/usr/local/pgsql/lib/libpq.so.5.3
00290000-00291000 rwxp 0001b000 fd:00 2019039
/usr/local/pgsql/lib/libpq.so.5.3
004f4000-004fd000 r-xp 00000000 fd:00 1659894    /lib/libnss_files-2.5.so
004fd000-004fe000 r-xp 00008000 fd:00 1659894    /lib/libnss_files-2.5.so
004fe000-004ff000 rwxp 00009000 fd:00 1659894    /lib/libnss_files-2.5.so
0065d000-00677000 r-xp 00000000 fd:00 1334309    /lib/ld-2.5.so
00677000-00678000 r-xp 00019000 fd:00 1334309    /lib/ld-2.5.so
00678000-00679000 rwxp 0001a000 fd:00 1334309    /lib/ld-2.5.so
0067b000-007bd000 r-xp 00000000 fd:00 1366888
/lib/i686/nosegneg/libc-2.5.so
007bd000-007be000 --xp 00142000 fd:00 1366888
/lib/i686/nosegneg/libc-2.5.so
007be000-007c0000 r-xp 00142000 fd:00 1366888
/lib/i686/nosegneg/libc-2.5.so
007c0000-007c1000 rwxp 00144000 fd:00 1366888
/lib/i686/nosegneg/libc-2.5.so
007c1000-007c4000 rwxp 007c1000 00:00 0
007c6000-007eb000 r-xp 00000000 fd:00 1367136
/lib/i686/nosegneg/libm-2.5.so
007eb000-007ec000 r-xp 00024000 fd:00 1367136
/lib/i686/nosegneg/libm-2.5.so
007ec000-007ed000 rwxp 00025000 fd:00 1367136
/lib/i686/nosegneg/libm-2.5.so
007f5000-00809000 r-xp 00000000 fd:00 1366910
/lib/i686/nosegneg/libpthread-2.5.so
00809000-0080a000 r-xp 00013000 fd:00 1366910
/lib/i686/nosegneg/libpthread-2.5.so
0080a000-0080b000 rwxp 00014000 fd:00 1366910
/lib/i686/nosegneg/libpthread-2.5.so
0080b000-0080d000 rwxp 0080b000 00:00 0
0081e000-0081f000 r-xp 0081e000 00:00 0          [vdso]
008b8000-008c8000 r-xp 00000000 fd:00 2019731
/usr/local/pgsql/lib/libecpg.so.6.2
008c8000-008c9000 rwxp 0000f000 fd:00 2019731
/usr/local/pgsql/lib/libecpg.so.6.2
008c9000-00989000 rwxp 008c9000 00:00 0
0518c000-05197000 r-xp 00000000 fd:00 1334378
/lib/libgcc_s-4.1.2-20080825.so.1
05197000-05198000 rwxp 0000a000 fd:00 1334378
/lib/libgcc_s-4.1.2-20080825.so.1
0537a000-0545a000 r-xp 00000000 fd:00 1279105    /usr/lib/libstdc++.so.6.0.8
0545a000-0545e000 r-xp 000df000 fd:00 1279105    /usr/lib/libstdc++.so.6.0.8
0545e000-0545f000 rwxp 000e3000 fd:00 1279105    /usr/lib/libstdc++.so.6.0.8
0545f000-05465000 rwxp 0545f000 00:00 0
05584000-0558d000 r-xp 00000000 fd:00 1659825    /lib/libcrypt-2.5.so
0558d000-0558e000 r-xp 00008000 fd:00 1659825    /lib/libcrypt-2.5.so
0558e000-0558f000 rwxp 00009000 fd:00 1659825    /lib/libcrypt-2.5.so
0558f000-055b6000 rwxp 0558f000 00:00 0
08048000-08050000 r-xp 00000000 03:41 6455433
/app/new-mchs/MCHS/trunk/src/repository/sid-search/mainprog
08050000-08051000 rw-p 00008000 03:41 6455433
/app/new-mchs/MCHS/trunk/src/repository/sid-search/mainprog
09acc000-09aed000 rw-p 09acc000 00:00 0
b7f02000-b7f05000 rw-p b7f02000 00:00 0
b7f13000-b7f15000 rw-p b7f13000 00:00 0
bf870000-bf885000 rw-p bffea000 00:00 0          [stack]
Abort

Hi Paul,

could you compile ecpg with debugging enabled and then run your test case under
gdb? A run under valgrind might help too. This bug shows some memory
corruption, so I need to figure out where exatly this happens.

Alternatively a small test case with which I can reproduce the problem on my
system is an option too.

Thanks a lot for your effort.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Here is what I got.  The gdb output does not see to be helpful and the
valgrind run seems to have executed without hitting the error. (I've
never used it before.)

Paul

lyta > sid-search > gdb -c core.*
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Core was generated by `mainprog test-data/test2.nist'.
Program terminated with signal 6, Aborted.
#0  0x005e0402 in __kernel_vsyscall ()
(gdb) bt
#0  0x005e0402 in __kernel_vsyscall ()
#1  0x006a4040 in ?? ()
(gdb) q

===========================================

lyta > sid-search > valgrind mainprog test-data/test2.nist
==4951== Memcheck, a memory error detector
==4951== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4951== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4951== Command: mainprog test-data/test2.nist
==4951==

Before calling tpalloc routine...

tot              : CON
nist file name   : test-data/test2.nist

Connected to database OK
SID Search initialized...

Before calling tpcall routine...

=========================  Fri May  7 15:13:53 2010
=========================

TOT CON From AFIS ID , To AFIS ID

Validating SID Search input buffer

Reusing existing database connection

NIST file opened OK (from buffer)

(((  Some program output deleted  )))

Tpreturn with code 0
==4951== Invalid read of size 1
==4951==    at 0x4006808: strlen (mc_replace_strmem.c:275)
==4951==    by 0x4151C0D: vfprintf (in /lib/libc-2.5.so)
==4951==    by 0x416C89B: vsprintf (in /lib/libc-2.5.so)
==4951==    by 0x4157EFD: sprintf (in /lib/libc-2.5.so)
==4951==    by 0x804AF93: build_query (sid_search.pc:336)
==4951==    by 0x804AEE5: do_sid_search (sid_search.pc:307)
==4951==    by 0x804AA91: SID_SEARCH (sid_search.pc:185)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==  Address 0x42aa998 is 24 bytes inside a block of size 108 free'd
==4951==    at 0x400551D: free (vg_replace_malloc.c:325)
==4951==    by 0x804AA51: SID_SEARCH (sid_search.pc:181)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==
==4951== Invalid read of size 1
==4951==    at 0x4006813: strlen (mc_replace_strmem.c:275)
==4951==    by 0x4151C0D: vfprintf (in /lib/libc-2.5.so)
==4951==    by 0x416C89B: vsprintf (in /lib/libc-2.5.so)
==4951==    by 0x4157EFD: sprintf (in /lib/libc-2.5.so)
==4951==    by 0x804AF93: build_query (sid_search.pc:336)
==4951==    by 0x804AEE5: do_sid_search (sid_search.pc:307)
==4951==    by 0x804AA91: SID_SEARCH (sid_search.pc:185)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==  Address 0x42aa999 is 25 bytes inside a block of size 108 free'd
==4951==    at 0x400551D: free (vg_replace_malloc.c:325)
==4951==    by 0x804AA51: SID_SEARCH (sid_search.pc:181)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==
==4951== Invalid read of size 1
==4951==    at 0x41775F0: _IO_default_xsputn (in /lib/libc-2.5.so)
==4951==    by 0x4151735: vfprintf (in /lib/libc-2.5.so)
==4951==    by 0x416C89B: vsprintf (in /lib/libc-2.5.so)
==4951==    by 0x4157EFD: sprintf (in /lib/libc-2.5.so)
==4951==    by 0x804AF93: build_query (sid_search.pc:336)
==4951==    by 0x804AEE5: do_sid_search (sid_search.pc:307)
==4951==    by 0x804AA91: SID_SEARCH (sid_search.pc:185)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==  Address 0x42aa998 is 24 bytes inside a block of size 108 free'd
==4951==    at 0x400551D: free (vg_replace_malloc.c:325)
==4951==    by 0x804AA51: SID_SEARCH (sid_search.pc:181)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==
==4951== Invalid read of size 1
==4951==    at 0x4177600: _IO_default_xsputn (in /lib/libc-2.5.so)
==4951==    by 0x4151735: vfprintf (in /lib/libc-2.5.so)
==4951==    by 0x416C89B: vsprintf (in /lib/libc-2.5.so)
==4951==    by 0x4157EFD: sprintf (in /lib/libc-2.5.so)
==4951==    by 0x804AF93: build_query (sid_search.pc:336)
==4951==    by 0x804AEE5: do_sid_search (sid_search.pc:307)
==4951==    by 0x804AA91: SID_SEARCH (sid_search.pc:185)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==  Address 0x42aa99a is 26 bytes inside a block of size 108 free'd
==4951==    at 0x400551D: free (vg_replace_malloc.c:325)
==4951==    by 0x804AA51: SID_SEARCH (sid_search.pc:181)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==
SQL statement: SELECT afis_key FROM person WHERE sid = 'MS04228464'

status: 1
message: FROM SID not found
Query returned 0 row(s).  From_afis_id:

==4951== Invalid free() / delete / delete[]
==4951==    at 0x400551D: free (vg_replace_malloc.c:325)
==4951==    by 0x804AB52: SID_SEARCH (sid_search.pc:194)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==  Address 0x42aa980 is 0 bytes inside a block of size 108 free'd
==4951==    at 0x400551D: free (vg_replace_malloc.c:325)
==4951==    by 0x804AA51: SID_SEARCH (sid_search.pc:181)
==4951==    by 0x804A374: main (mainprog.c:57)
==4951==
Tpreturn with code 0
Call complete, Status code 1, message [FROM SID not found]


Normal end of the SID_SEARCH program.....
==4951==
==4951== HEAP SUMMARY:
==4951==     in use at exit: 35,256 bytes in 74 blocks
==4951==   total heap usage: 191 allocs, 118 frees, 51,020 bytes allocated
==4951==
==4951== LEAK SUMMARY:
==4951==    definitely lost: 0 bytes in 0 blocks
==4951==    indirectly lost: 0 bytes in 0 blocks
==4951==      possibly lost: 143 bytes in 1 blocks
==4951==    still reachable: 35,113 bytes in 73 blocks
==4951==         suppressed: 0 bytes in 0 blocks
==4951== Rerun with --leak-check=full to see details of leaked memory
==4951==
==4951== For counts of detected and suppressed errors, rerun with: -v
==4951== ERROR SUMMARY: 22 errors from 5 contexts (suppressed: 29 from 11)
lyta > sid-search >


On 5/7/10 3:00 PM, Michael Meskes wrote:
> Hi Paul,
>
> could you compile ecpg with debugging enabled and then run your test case under
> gdb? A run under valgrind might help too. This bug shows some memory
> corruption, so I need to figure out where exatly this happens.
>
> Alternatively a small test case with which I can reproduce the problem on my
> system is an option too.
>
> Thanks a lot for your effort.
>
> Michael
>

It reviewing the output, I'm thinking this is a bug in my test
framework, not in ecpg.  Do you agree?

Paul


On 5/7/10 3:00 PM, Michael Meskes wrote:
> Hi Paul,
>
> could you compile ecpg with debugging enabled and then run your test case under
> gdb? A run under valgrind might help too. This bug shows some memory
> corruption, so I need to figure out where exatly this happens.
>
> Alternatively a small test case with which I can reproduce the problem on my
> system is an option too.
>
> Thanks a lot for your effort.
>
> Michael
>

On Fri, May 07, 2010 at 03:23:04PM -0400, Paul Anderson wrote:
> Here is what I got.  The gdb output does not see to be helpful and

You probaly have to compile libecpg without -O2 and with -g first.

> the valgrind run seems to have executed without hitting the error.
> (I've never used it before.)

It does show and invalid free though, but apparently that one comes from your
framework.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Fri, May 07, 2010 at 03:38:45PM -0400, Paul Anderson wrote:
> It reviewing the output, I'm thinking this is a bug in my test
> framework, not in ecpg.  Do you agree?

Maybe, I don't knwo enough about it to tell for sure, though.

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL