Re: bsqldb SEGFAULT abend

Hi folks,

I run it with MALLOC_CHECK_ set, and also under valgrind. The results
follow. Would please have a look at it?

Best Regards,

Ronildo
____________________________________________________________________________
___________________

MALLOC_CHECK_

[aum@ctmserver ~]$ export MALLOC_CHECK_=3
[aum@ctmserver ~]$ bsqldb -S aumdomain -U aum -P xxxxxxx -D ctm
malloc: using debugging hooks
select cmd_LINE from BSQLDB_TEST;
go
cmd_LINE
--------
ctmcontb
ctmcontb
*** glibc detected *** bsqldb: realloc(): invalid pointer: 0x0877a330 ***
======= Backtrace: =========
/lib/libc.so.6[0xb50cf7]
/lib/libc.so.6(realloc+0x3c)[0xb5128c]
/usr/local/lib/libsybdb.so.5[0x132379]
/usr/local/lib/libsybdb.so.5[0x13265a]
/usr/local/lib/libsybdb.so.5[0x134989]
/usr/local/lib/libsybdb.so.5(dbnextrow+0x2a7)[0x120a47]
bsqldb[0x804aae5]
/lib/libc.so.6(__libc_start_main+0xe0)[0xafa390]
bsqldb[0x80491c1]
======= Memory map: ========
00110000-00111000 r-xp 00110000 00:00 0          [vdso]
00111000-00167000 r-xp 00000000 fd:00 146136
/usr/local/lib/libsybdb.so.5.0.0
00167000-0016a000 rwxp 00056000 fd:00 146136
/usr/local/lib/libsybdb.so.5.0.0
0016a000-00174000 r-xp 00000000 fd:00 524329     /lib/libnss_files-2.7.so
00174000-00175000 r-xp 00009000 fd:00 524329     /lib/libnss_files-2.7.so
00175000-00176000 rwxp 0000a000 fd:00 524329     /lib/libnss_files-2.7.so
00176000-00177000 r-xp 00000000 fd:00 229580     /usr/lib/gconv/ISO8859-1.so
00177000-00178000 r-xp 00000000 fd:00 229580     /usr/lib/gconv/ISO8859-1.so
00178000-00179000 rwxp 00001000 fd:00 229580     /usr/lib/gconv/ISO8859-1.so
00179000-0017b000 r-xp 00000000 fd:00 229408     /usr/lib/gconv/CP1252.so
0017b000-0017c000 r-xp 00001000 fd:00 229408     /usr/lib/gconv/CP1252.so
0017c000-0017d000 rwxp 00002000 fd:00 229408     /usr/lib/gconv/CP1252.so
0090c000-00917000 r-xp 00000000 fd:00 526979
/lib/libgcc_s-4.1.2-20070925.so.1
00917000-00918000 rwxp 0000a000 fd:00 526979
/lib/libgcc_s-4.1.2-20070925.so.1
00ac1000-00adc000 r-xp 00000000 fd:00 526962     /lib/ld-2.7.so
00adc000-00add000 r-xp 0001a000 fd:00 526962     /lib/ld-2.7.so
00add000-00ade000 rwxp 0001b000 fd:00 526962     /lib/ld-2.7.so
00ae4000-00c37000 r-xp 00000000 fd:00 526963     /lib/libc-2.7.so
00c37000-00c39000 r-xp 00153000 fd:00 526963     /lib/libc-2.7.so
00c39000-00c3a000 rwxp 00155000 fd:00 526963     /lib/libc-2.7.so
00c3a000-00c3d000 rwxp 00c3a000 00:00 0
00c71000-00c86000 r-xp 00000000 fd:00 526964     /lib/libpthread-2.7.so
00c86000-00c87000 r-xp 00014000 fd:00 526964     /lib/libpthread-2.7.so
00c87000-00c88000 rwxp 00015000 fd:00 526964     /lib/libpthread-2.7.so
00c88000-00c8a000 rwxp 00c88000 00:00 0
00daf000-00db6000 r-xp 00000000 fd:00 526965     /lib/librt-2.7.so
00db6000-00db7000 r-xp 00007000 fd:00 526965     /lib/librt-2.7.so
00db7000-00db8000 rwxp 00008000 fd:00 526965     /lib/librt-2.7.so
08048000-0804d000 r-xp 00000000 fd:00 146143     /usr/local/bin/bsqldb
0804d000-0804e000 rw-p 00004000 fd:00 146143     /usr/local/bin/bsqldb
08743000-08789000 rw-p 08743000 00:00 0
b7f05000-b7f06000 rw-p b7f05000 00:00 0
b7f07000-b7f09000 rw-p b7f07000 00:00 0
b7f09000-b7f10000 r--s 00000000 fd:00 229659
/usr/lib/gconv/gconv-modules.cache
b7f10000-b7f12000 rw-p b7f10000 00:00 0
bffa0000-bffb5000 rw-p bffea000 00:00 0          [stack]
Abortado
[aum@ctmserver ~]$
____________________________________________________________________________
___________________

VALGRIND

[aum@ctmserver valgrind-3.5.0]$ valgrind --leak-check=full bsqldb -S
aumdomain -U aum -P xxxxxxx -D ctm
==28684== Memcheck, a memory error detector
==28684== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==28684== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==28684== Command: bsqldb -S aumdomain -U aum -P aum194 -D ctm
==28684==
select CMD_LINE from BSQLDB_TEST;
go
CMD_LINE
--------
==28684== Invalid write of size 1
==28684==    at 0x4007BCA: memcpy (mc_replace_strmem.c:482)
==28684==    by 0x401804C: buffer_transfer_bound_data (dblib.c:7143)
==28684==    by 0x401994A: dbnextrow (dblib.c:2024)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==  Address 0x40cb6a0 is 0 bytes after a block of size 8 alloc'd
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x804A363: main (bsqldb.c:405)
==28684==
==28684== Invalid write of size 1
==28684==    at 0x4007BD2: memcpy (mc_replace_strmem.c:482)
==28684==    by 0x401804C: buffer_transfer_bound_data (dblib.c:7143)
==28684==    by 0x401994A: dbnextrow (dblib.c:2024)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==  Address 0x40cb6a1 is 1 bytes after a block of size 8 alloc'd
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x804A363: main (bsqldb.c:405)
==28684==
==28684== Invalid write of size 1
==28684==    at 0x4007BDB: memcpy (mc_replace_strmem.c:482)
==28684==    by 0x401804C: buffer_transfer_bound_data (dblib.c:7143)
==28684==    by 0x401994A: dbnextrow (dblib.c:2024)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==  Address 0x40cb6a2 is 2 bytes after a block of size 8 alloc'd
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x804A363: main (bsqldb.c:405)
==28684==
==28684== Invalid write of size 1
==28684==    at 0x4007BE4: memcpy (mc_replace_strmem.c:482)
==28684==    by 0x401804C: buffer_transfer_bound_data (dblib.c:7143)
==28684==    by 0x401994A: dbnextrow (dblib.c:2024)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==  Address 0x40cb6a3 is 3 bytes after a block of size 8 alloc'd
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x804A363: main (bsqldb.c:405)
==28684==
==28684== Invalid write of size 1
==28684==    at 0x4007C09: memcpy (mc_replace_strmem.c:482)
==28684==    by 0x401804C: buffer_transfer_bound_data (dblib.c:7143)
==28684==    by 0x401994A: dbnextrow (dblib.c:2024)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==  Address 0x40cb6b4 is not stack'd, malloc'd or (recently) free'd
==28684==
==28684== Invalid write of size 1
==28684==    at 0x4018075: buffer_transfer_bound_data (dblib.c:7146)
==28684==    by 0x401994A: dbnextrow (dblib.c:2024)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==  Address 0x40cb6b6 is not stack'd, malloc'd or (recently) free'd
==28684==
ctmcontb
ctmcontb
.......
ctmdbcou
44 rows affected
<ctrl+D>
==28684==
==28684== HEAP SUMMARY:
==28684==     in use at exit: 224,456 bytes in 71 blocks
==28684==   total heap usage: 270 allocs, 199 frees, 365,046 bytes allocated
==28684==
==28684== 8 bytes in 1 blocks are possibly lost in loss record 16 of 71
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x8049F8A: main (bsqldb.c:329)
==28684==
==28684== 8 bytes in 1 blocks are possibly lost in loss record 17 of 71
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x804A363: main (bsqldb.c:405)
==28684==
==28684== 10 bytes in 1 blocks are possibly lost in loss record 22 of 71
==28684==    at 0x4005A42: realloc (vg_replace_malloc.c:476)
==28684==    by 0x402B378: tds_get_data (token.c:2043)
==28684==    by 0x402B659: tds_process_row (token.c:2168)
==28684==    by 0x402D988: tds_process_tokens (token.c:623)
==28684==    by 0x4019A46: dbnextrow (dblib.c:1994)
==28684==    by 0x804AAE4: main (bsqldb.c:514)
==28684==
==28684== 41 (24 direct, 17 indirect) bytes in 1 blocks are definitely lost
in loss record 40 of 71
==28684==    at 0x4004C82: calloc (vg_replace_malloc.c:418)
==28684==    by 0x8049F66: main (bsqldb.c:326)
==28684==
==28684== 181 (4 direct, 177 indirect) bytes in 1 blocks are definitely lost
in loss record 57 of 71
==28684==    at 0x4005943: malloc (vg_replace_malloc.c:195)
==28684==    by 0x401BC1E: dblogin (dblib.c:694)
==28684==    by 0x804955D: get_login (bsqldb.c:766)
==28684==    by 0x8049B72: main (bsqldb.c:118)
==28684==
==28684== LEAK SUMMARY:
==28684==    definitely lost: 28 bytes in 2 blocks
==28684==    indirectly lost: 194 bytes in 9 blocks
==28684==      possibly lost: 26 bytes in 3 blocks
==28684==    still reachable: 224,208 bytes in 57 blocks
==28684==         suppressed: 0 bytes in 0 blocks
==28684== Reachable blocks (those to which a pointer was found) are not
shown.
==28684== To see them, rerun with: --leak-check=full --show-reachable=yes
==28684==
==28684== For counts of detected and suppressed errors, rerun with: -v
==28684== ERROR SUMMARY: 910 errors from 11 contexts (suppressed: 22 from
10)
[aum@ctmserver valgrind-3.5.0]$
____________________________________________________________________________
___________________

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Christos Zoulas
Sent: quinta-feira, 1 de abril de 2010 10:01
To: FreeTDS Development Group
Subject: Re: [freetds] bsqldb SEGFAULT abend

On Mar 31,  8:19pm, [email protected] ("James K. Lowden") wrote:
-- Subject: Re: [freetds] bsqldb SEGFAULT abend

| Ronildo wrote:
| > 
| > Program received signal SIGSEGV, Segmentation fault.
| > [Switching to Thread -1208239392 (LWP 20221)] 0x00b5143d in realloc 
| > () from /lib/libc.so.6
| > (gdb) bt
| > #0  0x00b5143d in realloc () from /lib/libc.so.6
| > #1  0x00132379 in tds_get_data (tds=0x8097ad0, curcol=0x80cad10) at
| > token.c:2043
| > #2  0x0013265a in tds_process_row (tds=0x8097ad0) at token.c:2168
| > #3  0x00134989 in tds_process_tokens (tds=0x8097ad0, 
| > #result_type=0xbf940188,
| >     done_flags=0x0, flag=5384) at token.c:623
| > #4  0x00120a47 in dbnextrow (dbproc=0x8097360) at dblib.c:1994
| > #5  0x0804aae5 in main (argc=Cannot access memory at address 0x4
| > ) at bsqldb.c:514
| 
| Well, that's bad.  It looks to me like memory corruption, because all 
| that's ever supposed to be stored in blob->textpointer is a pointer 
| returned by malloc/realloc.
| 
| One possibilty is that determine_adjusted_size() somehow returns a 
| negative value, leading realloc() to ask for something huge.  (There 
| are quite a few places in the code where int is used where size_t 
| would be preferable.  This might be one.)
| 
| One thing you could do is add
| 
| 	assert(new_blob_size > 0);
| 
| as soon as it's assigned.  Also see MALLOC_CHECK_ in your realloc() 
| man page.
| 
| I consider any segment fault a serious error, and I very much wnat to 
| get to the bottom of it.  It will be hard to reproduce, though, even 
| with the details you've provided.  The more you're able to do on your 
| end, the better.
| 
| (Then again, it seems Frediano commits a fix everytime I make a speech 
| like that....)
| 

Run it through valgrind...

christos
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds