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

[David Brooks]

Hmm, I wonder if this also behind the issues I've found with the Python 
bindings at program exit -- see 
http://bugs.librdf.org/mantis/view.php?id=531


Regards,
Dave

On 13/03/13 11:24 AM, Norman Gray wrote:
> 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 ()
> [...]
>