[redland-dev] What needs to be tidied away at the end of a librdf program?

[Norman Gray]

Greetings.

What clearup is necessary at the end of a program using librdf?  Can I just let everything drop, or is there (for example) storage cleanup that is necessary?

I'm working on wrapping librdf in Racket (a scheme-lineage lisp, <http://racket-lang.org>, and see <https://bitbucket.org/nxg/racket-librdf>).  

I'm getting some access violations (see stack traces below) in Racket program finalisation code, which is scrupulously freeing everything in sight.  I rather suspect that this is because librdf isn't necessarily designed to work in the presence of a garbage collector, which may or may not respect interdependencies between librdf objects which aren't manifest in the higher layer.  This may be a fault in my wrapping, or a fault in librdf, but I'm not reporting it at a librdf bug because I haven't investigated it in much detail.

I haven't investigated it because I suspect it doesn't matter, if it only happens in cleanup code (and that's a fairly big 'if' which I haven't yet fully convinced myself of).

So, the point: is it likely to be safe for me to simply skip the at-exit cleanup, and let everything be tidied up by the program exit?  I'm guessing yes; the only exception I can think of is storage cleanup, and I'd suppose that a call to librdf_storage_sync would take care of that.

Thanks for any advice.

Best wishes,

Norman

----

#0  0x0000000104cad080 in raptor_free_uri (uri=0x100515230) at raptor_uri.c:492
492	  if(uri->world->uris_tree)
(gdb) where
#0  0x0000000104cad080 in raptor_free_uri (uri=0x100515230) at raptor_uri.c:492
#1  0x0000000104cb3195 in raptor_free_term (term=0x100515230) at raptor_term.c:407
#2  0x0000000104cb2a8d in raptor_statement_clear [inlined] () at /Data/tools/000-build/raptor2-2.0.9/src/raptor_statement.c:203
#3  0x0000000104cb2a8d in raptor_free_statement (statement=0x100515230) at raptor_statement.c:236
#4  0x000000010029d51f in scheme_run_atexit_closers ()
#5  0x00000001002a196a in scheme_do_close_managed ()
#6  0x00000001002a1e42 in scheme_run_atexit_closers_on_all ()
#7  0x00007fff8d2ff30b in __cxa_finalize ()
#8  0x00007fff8d300f57 in exit ()
#9  0x00000001000479d9 in def_exit_handler_proc ()
#10 0x0000000100063ba1 in scheme_do_eval ()
#11 0x0000000100083763 in apply_k ()
#12 0x00000001000847ae in scheme_top_level_do_worker ()
#13 0x00000001000478dd in scheme_do_exit ()
[...]

-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK