Re: 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....)

Regards, 

--jkl