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

From: Eli Barzilay (eli at barzilay.org)
Date: Sat Jul 28 01:18:10 EDT 2007

On Jul 27, Keith Frost wrote:
> On 7/27/07, Eli Barzilay <eli at barzilay.org> wrote:
> >
> > 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?

No, the danger is not that it will be GCed -- it's that a GC moves the
pointer to a different place, so it might be that sqlite now has a
pointer that is no longer valid.


> 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?

No.


> 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.

If it happens when there's lots of data, then it is probably a result
of the GC moving pointers.  (But I cannot say much more...)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the users mailing list.