Re: Glibc error using ecpg

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
>