[redland-dev] redland-dev Digest, Vol 121, Issue 3
Slava Kravchenko
slava.kravchenko at gmail.com
Wed Mar 13 13:46:46 EDT 2013
> 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>).
[skipped]
Hello Norman,
I cannot claim expertise in C, but I'm speaking from my experience
coding Ruby wrapper for Redland, Redlander. As I learnt the hard way,
one should pay attention to the description of the output of methods.
Some methods return a new value, others return a pointer to a shared
resource.
For instance, read the description for "librdf_statement_get_subject".
The output node value that you wrap in Racket must be *copied* from
the SHARED pointer of "librdf_statement_get_subject". Otherwise,
neither the statement nor the subject node can be safely
garbage-collected. Redland API provides methods for creating *new*
values from shared pointers, e.g.: "librdf_new_node_from_node" could
be used in this case.
As a side note, something is still "leaking" in my bindings, as I'm
occasionally getting "*** glibc detected *** /bin/ruby: corrupted
double-linked list: 0x0000000002d86fd0 ***" despite my best efforts
;-)
Best regards,
Slava Kravchenko
On Wed, Mar 13, 2013 at 7:00 PM, <redland-dev-request at lists.librdf.org> wrote:
> Send redland-dev mailing list submissions to
> redland-dev at lists.librdf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.librdf.org/mailman/listinfo/redland-dev
> or, via email, send a message with subject or body 'help' to
> redland-dev-request at lists.librdf.org
>
> You can reach the person managing the list at
> redland-dev-owner at lists.librdf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of redland-dev digest..."
>
>
> Today's Topics:
>
> 1. What needs to be tidied away at the end of a librdf program?
> (Norman Gray)
> 2. Re: What needs to be tidied away at the end of a librdf
> program? (David Brooks)
> 3. [Raptor RDF Syntax Library 0000532]: configure.ac: required
> file `src/raptor_config.h.in' not found (Mantis Bug Tracker)
> 4. [Raptor RDF Syntax Library 0000533]: Remove the
> raptor_last_known_good tag from Git (Mantis Bug Tracker)
> 5. Re: What needs to be tidied away at the end of a librdf
> program? (Norman Gray)
> 6. Announcing the first release of Kalimba (Slava Kravchenko)
> 7. Addenda to: Announcing the first release of Kalimba
> (Slava Kravchenko)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 12 Mar 2013 22:24:22 +0000
> From: Norman Gray <norman at astro.gla.ac.uk>
> To: redland-dev at lists.librdf.org
> Subject: [redland-dev] What needs to be tidied away at the end of a
> librdf program?
> Message-ID: <A41C8064-E9AB-4D0B-A354-92952C19E6F9 at astro.gla.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Mar 2013 13:11:06 +1300
> From: David Brooks <d.brooks at auckland.ac.nz>
> To: Norman Gray <norman at astro.gla.ac.uk>
> Cc: redland-dev at lists.librdf.org
> Subject: Re: [redland-dev] What needs to be tidied away at the end of
> a librdf program?
> Message-ID: <513FC41A.5040308 at auckland.ac.nz>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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 ()
>> [...]
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Mar 2013 02:35:45 +0100
> From: Mantis Bug Tracker <mantis-bug-sender at librdf.org>
> To: redland-dev at lists.librdf.org
> Subject: [redland-dev] [Raptor RDF Syntax Library 0000532]:
> configure.ac: required file `src/raptor_config.h.in' not found
> Message-ID: <a035b04abada5114c6da0a15b67ecd65 at bugs.librdf.org>
> Keywords: [Raptor RDF Syntax Library] installation
> Content-Type: text/plain; charset="utf-8"
>
>
> The following issue has been SUBMITTED.
> ======================================================================
> http://bugs.librdf.org/mantis/view.php?id=532
> ======================================================================
> Reported By: arto
> Assigned To:
> ======================================================================
> Project: Raptor RDF Syntax Library
> Issue ID: 532
> Category: installation
> Reproducibility: always
> Severity: block
> Priority: normal
> Status: new
> Syntax Name:
> ======================================================================
> Date Submitted: 2013-03-13 02:35
> Last Modified: 2013-03-13 02:35
> ======================================================================
> Summary: configure.ac: required file `src/raptor_config.h.in'
> not found
> Description:
> There seems to be a regression in the installation procedure from a Git
> checkout, wherein the ./autogen.sh procedure documented at
> http://librdf.org/raptor/INSTALL.html now aborts with the error:
>
> configure.ac:29: required file `src/raptor_config.h.in' not found
>
>
> Steps to Reproduce:
> $ git clone git://github.com/dajobe/raptor.git raptor
> $ cd raptor
> $ ./autogen.sh
>
>
> Additional Information:
> Please see the attached log for a full transcript.
>
> Running `autoreconf -fi` manually, followed by ./autogen.sh, fixes the issue and
> allows the installation to proceed; however, according to the installation
> instructions, this should be unnecessary (and it also used to be that
> ./autogen.sh was sufficient in and of itself).
>
> ======================================================================
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2013-03-13 02:35 arto New Issue
> 2013-03-13 02:35 arto File Added: raptor-autogen.log
>
> ======================================================================
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 13 Mar 2013 02:50:24 +0100
> From: Mantis Bug Tracker <mantis-bug-sender at librdf.org>
> To: redland-dev at lists.librdf.org
> Subject: [redland-dev] [Raptor RDF Syntax Library 0000533]: Remove the
> raptor_last_known_good tag from Git
> Message-ID: <c835a0734dbad5b675e670cfa01f305f at bugs.librdf.org>
> Keywords: [Raptor RDF Syntax Library] installation
> Content-Type: text/plain; charset="utf-8"
>
>
> The following issue has been SUBMITTED.
> ======================================================================
> http://bugs.librdf.org/mantis/view.php?id=533
> ======================================================================
> Reported By: arto
> Assigned To:
> ======================================================================
> Project: Raptor RDF Syntax Library
> Issue ID: 533
> Category: installation
> Reproducibility: N/A
> Severity: trivial
> Priority: none
> Status: new
> Syntax Name:
> ======================================================================
> Date Submitted: 2013-03-13 02:50
> Last Modified: 2013-03-13 02:50
> ======================================================================
> Summary: Remove the raptor_last_known_good tag from Git
> Description:
> Please consider removing the misleading 'raptor_last_known_good' tag from the
> Git repository, as contrary to its name it actually refers to a commit from way
> back in 2006:
>
> commit b5d6ebcdd884f1ff9d4be1b1cbe5a12570df933d
> Author: Dave Beckett <dave at dajobe.org>
> Date: Sun Feb 19 03:55:26 2006 +0000
>
> #changes
>
>
> Additional Information:
> $ git tag -d raptor_last_known_good
> $ git push origin :refs/tags/raptor_last_known_good
>
> ======================================================================
>
> Issue History
> Date Modified Username Field Change
> ======================================================================
> 2013-03-13 02:50 arto New Issue
> ======================================================================
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 13 Mar 2013 09:51:50 +0000
> From: Norman Gray <norman at astro.gla.ac.uk>
> To: David Brooks <d.brooks at auckland.ac.nz>
> Cc: redland-dev at lists.librdf.org
> Subject: Re: [redland-dev] What needs to be tidied away at the end of
> a librdf program?
> Message-ID: <B5A1ED03-93CD-49BB-8B05-C6AC1CF6EE05 at astro.gla.ac.uk>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> David and all, hello.
>
> On 2013 Mar 13, at 00:11, David Brooks <d.brooks at auckland.ac.nz> wrote:
>
>> Hmm, I wonder if this also behind the issues I've found with the Python bindings at program exit -- seehttp://bugs.librdf.org/mantis/view.php?id=531
>
> I've had broadly similar problems in this space before <http://bugs.librdf.org/mantis/view.php?id=365>, but I didn't link to that in the message because I'm not sure that these are immediately related. As Dave Beckett notes in the comments to that problem, there isn't an easy answer to this (of course!).
>
> It occurs to me that I should perhaps try building librdf with a GC library such as the Boehm one, and see what happens....
>
> Best wishes,
>
> Norman
>
>
> --
> Norman Gray : http://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 13 Mar 2013 13:42:40 +0300
> From: Slava Kravchenko <slava.kravchenko at gmail.com>
> To: "redland-dev at lists.librdf.org" <redland-dev at lists.librdf.org>,
> public-rdf-ruby at w3.org
> Subject: [redland-dev] Announcing the first release of Kalimba
> Message-ID:
> <CAMd1MeDZBOZnUQwf+quTeaOyO+ikjFyBzBCqS47MQXewxhcHiw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everybody!
>
> I'm extremely happy to announce that the first public version of Kalimba
> has been released!
>
> Kalimba is a Ruby gem (library) which provides ActiveRecord-like
> capabilities for your RDF data. You may think of it as a sibling of Spira,
> except that Kalimba is:
>
> - high performance-oriented,
> - lightweight,
> - based on Redlander* gem, which is based on Redland (librdf.org) and
> thus is not directly related to RDF.rb,
> - has more "Ruby-ish" API.
>
> * Redlander is currently the only "backend" for Kalimba, but owing to the
> modular architecture, more backends can be added. Even RDF.rb with its own
> backends.
>
> There are many exciting things in store for Kalimba/Redlander development,
> but it's already not a basic library and is being tested in production (in
> a private project).
>
> Best regards,
>
> Slava Kravchenko
> https://plus.google.com/109894007099276378025
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.librdf.org/pipermail/redland-dev/attachments/20130313/81429c91/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 13 Mar 2013 13:58:08 +0300
> From: Slava Kravchenko <slava.kravchenko at gmail.com>
> To: "redland-dev at lists.librdf.org" <redland-dev at lists.librdf.org>,
> public-rdf-ruby at w3.org
> Subject: [redland-dev] Addenda to: Announcing the first release of
> Kalimba
> Message-ID:
> <CAMd1MeBtYqQUofgva9-S-5y5RBnZ9AgbqxwTOVfDGPzmg6-mKA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In all the excitement I forgot to provide the links to the project. My
> apologies.
>
> Kalimba gem is hosted at rubygems.org:
> - https://rubygems.org/gems/kalimba
>
> The only backend is "kalimba-redlander":
> - https://rubygems.org/gems/kalimba-redlander
>
> If you want to go "deeper" and learn about Redlander gem:
> - https://rubygems.org/gems/redlander
>
> The development repositories are hosted at github. You can find the
> corresponding links as "homepage" links at rubygems.org.
>
> Best regards,
>
> Slava Kravchenko
> https://plus.google.com/109894007099276378025
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.librdf.org/pipermail/redland-dev/attachments/20130313/543c352c/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> redland-dev mailing list
> redland-dev at lists.librdf.org
> http://lists.librdf.org/mailman/listinfo/redland-dev
>
> End of redland-dev Digest, Vol 121, Issue 3
> *******************************************
More information about the redland-dev
mailing list