[redland-dev] Debugging redland memory across libraries

Dave Beckett dave.beckett at bristol.ac.uk
Thu May 19 11:07:09 BST 2005


During some jetlagged-recovery early mornings this week I created
what I've called "signed memory" debugging for raptor / rasqal /
redland which marks allocations (malloc) being made by one library
and checks when freed (free) that they came from the same library..
It's enabled by --with-memory-signing in CVS sources.  Don't turn it
on unless you are brave!

This allowed me to track when memory was allocated in one library and
freed in another which isn't a problem for single heap architectures
such as posix/unix/linux/osx but is for Windows DLLs which has caused
crashes, the latest of which John Barstow has mentioned in his
porting activities.

I found a couple of places this happened when querying is going on
inside redland (calling rasqal) and have fixed it in CVS.  This
needed API changes to both rasqal and redland so requires upgrading
of both.

This doesn't solve all such occasions as it might happen between
redland and bindings too.  I know that at least the
node/uri/model/... class to_string methods cause this problem
as they free() memory inside the binding DLL returned fromr edland.

What happens is approximately.

  redland (say librdf.dll):
    create a string version of the object by allocating some memory
    with malloc() in this library (aka redland_alloc_memory).

  SWIG interface binding (e.g. python lib)
    create a new python literal object with the string redland returned
    free() the string returned <-ERROR - this is across heaps

  python
    access the python literal

I'm not quite sure how to fix this yet, either modifying the SWIG
generated C code to do a redland_free_memory() instead of free() - a
simple substitution which works - or take some other approach.

Dave


More information about the redland-dev mailing list