FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

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