[plt-scheme] sqlite.plt seg faults with 370

On 7/27/07, Eli Barzilay <eli at barzilay.org> wrote:
> On Jul 27, Keith Frost wrote:
> > [...]
> > And it seems that some time between the calling of sqlite3_get_table,
> > and the extraction of some of the results with
> > cvector->list-of-vector, the block of memory pointed to by
> > result_ptr_ptr (which is apparently malloc'd by the sqlite3 library,
>
> Are you sure?  It looks like it's malloced in Scheme, and perhaps it's
> set by sqlite?

It seems that only the space for the one pointer is allocated in
Scheme -- the pointer is set by sqlite3 to point to a block of
pointers allocated by sqlite3, which point to C strings also allocated
by sqlite3.

>
> > along with the space for the strings to which it points) can get
> > clobbered.  This seems to be what's happening, and I guess it's
> > plausible that 3m might do this, but what I don't know is how to fix
> > it.  Can anybody here give me another clue?
>
> I don't know about the sqlite interface, but one thing that you can
> try is to use a raw malloc (add a 'raw flag to the malloc) -- this
> will use the system's malloc, which is completely ignored by the GC.
> This requires freeing the block explicitly, but the code already has a
> finalizer so it's easy.
>

I tried this -- but it didn't seem to help, and given that I didn't
think that the space for the pointer was getting GC'd anyway, I wasn't
too surprised that it didn't.  So, in theory at least, there isn't
anything I need to do to protect the memory malloc'd by sqlite3 from
getting messed up by the garbage collector?  Could calling
make-cvector*, and then dereferencing lots of pointers to C strings in
that block of memory, somehow make the GC start altering things?
Could there be a GC bug lurking here?  The problem exhibits itself
intermittently, but is more likely to happen as the size of the
returned table gets big (tens of thousands of rows).  Sometimes the
symptom is a segfault, and sometimes it is an error converting the C
pointer block into a string, because the pointer has been altered
somehow so that it points to nearby memory locations.

Thanks,

Keith F.