freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Ronildo" <rquadros AT hitsfactory.net>
- To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] bsqldb SEGFAULT abend
- Date: Thu, 1 Apr 2010 12:54:32 -0300
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: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] 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, jklowden AT freetds.org ("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
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
-
Re: [freetds] bsqldb SEGFAULT abend,
Christos Zoulas, 04/01/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
Ronildo, 04/01/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
Ronildo, 04/01/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
James K. Lowden, 04/01/2010
- Re: [freetds] bsqldb SEGFAULT abend, Ronildo, 04/03/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
James K. Lowden, 04/03/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
Ronildo, 04/05/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
jklowden, 04/05/2010
- Re: [freetds] bsqldb SEGFAULT abend, Ronildo, 04/05/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
jklowden, 04/05/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
Ronildo, 04/05/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
James K. Lowden, 04/01/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
Ronildo, 04/01/2010
-
Re: [freetds] bsqldb SEGFAULT abend,
Ronildo, 04/01/2010
Archive powered by MHonArc 2.6.24.