FreeTDS Development Group

["Ronildo" <rquadros AT hitsfactory.net>]

Hi James,

Thanks for taking the time to help us. Here is gdb session log.

Rio de Janeiro sends you our best regards.

Ronildo
____________________________________________________________________________
__________________________________________

[aum@ctmserver freetds-0.82]$ gdb
GNU gdb Red Hat Linux (6.6-35.fc8rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
(gdb) file bsqldb
Reading symbols from /usr/local/bin/bsqldb...done.
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -S aumdomain -U aum -P xxxxxxx -D ctm
Starting program: /usr/local/bin/bsqldb -S aumdomain -U aum -P xxxxxxx -D
ctm

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/ac/2eeb206486bb7315d6ac4cd64de0cb50838ff6.debug

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/e3/3448de964a5ca97b70edbdcea227c6ea5d3657.debug

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/6c/1cdbb38ae2a292613c8c31195417ee80ea7e1e.debug
[Thread debugging using libthread_db enabled]
[New process 20221]

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/ba/4ea1118691c826426e9410cafb798f25cefad5.debug
[New Thread -1208239392 (LWP 20221)]

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/a7/eabb854181ef5ff0c22b78c3e5048c64a2ebb8.debug

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/b4/8fdd084f9abacb1e4369c7e2cba189e3507926.debug

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/c6/bac4cd825ae702bcbf5dc7327c17529b8757aa.debug
select CMD_LINE from BSQLDB_TEST;
go
CMD_LINE
--------
ctmcontb
ctmcontb

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
(gdb)
____________________________________________________________________________
__________________________________________

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: terça-feira, 30 de março de 2010 19:59
To: FreeTDS Development Group
Subject: Re: [freetds] bsqldb SEGFAULT abend

Ronildo Quadros wrote:
>  
> your client OS and hardware architecture:  Linux Fedora Core 8 virtual 
> machine under VMWare hosted by Windows 2003 Server - Intel P4

Interesting....   I wonder if you've uncovered soemthing.  

My compliments on a fine problem report, by the way.  :-)

> [aum@ctmserver freetds-0.82]$ bsqldb -S aumdomain -U aum -P xxxxx -D 
> ctm select CMD_LINE from BSQLDB_TEST; go CMD_LINE
> --------
> ctmcontb
> ctmcontb
> Segmentation Fault <== this line was translated from portuguese

Gah. 

> I looked into the source for BSLQDB and it seems that line 405 
> should/could read:
>  
> data[c].buffer = calloc(1, metadata[c].size);
>  
> instead of:
>  
> data[c].buffer = calloc(1, metadata[c].width);

No, sadly, that's not it.  The .size member represents the size as reported
by the server; the .width member represents the printable size. 
Approximately it's the difference between

        int i = 1 << 10;
        char buf[20];
        int size = sizeof(i);
        int width = sprintf(buf, "%d", i);

We're asking dbbind() to convert data to a string and place the string in
our buffer (from which we'll print it).  (In this case, though, it's
character data, so width == size.)  

I'm afraid the best way I know to debug this is with the debugger.  Make
sure your binaries have symbols (compiled as debug and not stripped). Get a
core dump or run bsqldb inside gdb until the fault. Use the "bt" command to
see the backtrace.  That will show the call sequence and the point of
failure.  Usually that's enough information.  

I'd be happy to fix this if we can find it.  

Regards, 

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds