The following issue has been SUBMITTED. ====================================================================== http://bugs.librdf.org/mantis/view.php?id=478 ====================================================================== Reported By: normang Assigned To: ====================================================================== Project: Redland librdf RDF API Issue ID: 478 Category: api Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2011-10-29 19:30 Last Modified: 2011-10-29 19:30 ====================================================================== Summary: Object returned from librdf_stream_get_object must be copied, but may not copiable Description: The documentation for librdf_stream_get_object says:
This method returns a SHARED pointer to the current statement object which should be copied by the caller to preserve it if the stream is moved on librdf_stream_next or if it should last after the stream is closed. The obvious function to copy this is librdf_new_statement_from_statement, which says: Copy constructor - create a new librdf_statement from an existing librdf_statement. However, the 'copy' which this returns is not an independent copy, but, via raptor_statement_copy, merely the original statement with an incremented usage count (unless the input statement is static (usage < 0); see raptor_statement_copy in https://github.com/dajobe/raptor/blob/master/src/raptor_statement.c), and this is confirmed by printing out pointers and usage counts of the statement returned from librdf_new_statement_from_statement. >From its description, I would expect librdf_new_... to produce a new librdf_statement instance, with a usage count of 1. The librdf_new_... function is therefore not a suitable function to use to make a safe copy of the statement returned from librdf_stream_get_object. Thus, either librdf_new_... is not implementing its documentation correctly (is there perhaps a slippage between librdf_new_... and raptor_statement_copy which means that the former can't reliably delegate to the latter), or else the librdf_stream_get_object documentation needs to be more explicit about how this safe copy is to be achieved. Steps to Reproduce: This is perfectly reproducible in my usage of the library, but I haven't made a separate reduction. In my usage of the library, I'm reading all of the statements from the stream in turn, but these are being managed by the caller, as a group. The program ends up with all of the collected statements being identical. Is the above explanation convincing alone? My code: if ((statement = librdf_stream_get_object(stream)) == NULL) { return scheme_false; } else { librdf_statement* orig_statement; orig_statement = statement; if ((statement = librdf_new_statement_from_statement(orig_statement)) == NULL) { scheme_signal_error("Error copy-constructing statement"); } fprintf(stderr, "get_stream_next: orig_statement=%p(%d) statement=%p(%d)\n", orig_statement, ((raptor_statement*)orig_statement)->usage, statement, ((raptor_statement*)statement)->usage); fprintf(stderr, "get_stream_next: %s\n", statement_to_string_internal(statement)); librdf_stream_next(stream); /* move the stream up one */ return statement; } My debugging output: hashes store: get_stream_next: <http://nxg.me.uk/norman/> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> get_stream_next: orig_statement=0x1018160d0(2) statement=0x1018160d0(2) get_stream_next: <http://nxg.me.uk/norman/> <http://purl.org/dc/terms/name> "Norman" get_stream_next: orig_statement=0x101817460(2) statement=0x101817460(2) get_stream_next: _:r1319914503r13273r1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> get_stream_next: orig_statement=0x101820620(2) statement=0x101820620(2) get_stream_next: _:r1319914503r13273r1 <http://xmlns.com/foaf/0.1/homepage> <http://example.com/person> get_stream_next: orig_statement=0x101816e90(2) statement=0x101816e90(2) get_stream_next: <http://nxg.me.uk/norman/> <http://xmlns.com/foaf/0.1/knows> _:r1319914503r13273r1 get_stream_next: orig_statement=0x10181b430(2) statement=0x10181b430(2) get_stream_next: <http://nxg.me.uk/norman/> <http://xmlns.com/foaf/0.1/mbox> <mailto:[email protected]> (note, problem is masked here, because the orig_statement is different each time) sqlite store: get_stream_next: orig_statement=0x10181ebb0(2) statement=0x10181ebb0(2) get_stream_next: <http://nxg.me.uk/norman/> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> get_stream_next: orig_statement=0x10181ebb0(3) statement=0x10181ebb0(3) get_stream_next: <http://nxg.me.uk/norman/> <http://purl.org/dc/terms/name> "Norman" get_stream_next: orig_statement=0x10181ebb0(4) statement=0x10181ebb0(4) get_stream_next: _:r1319914503r13273r3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> get_stream_next: orig_statement=0x10181ebb0(5) statement=0x10181ebb0(5) get_stream_next: _:r1319914503r13273r3 <http://xmlns.com/foaf/0.1/homepage> <http://example.com/person> get_stream_next: orig_statement=0x10181ebb0(6) statement=0x10181ebb0(6) get_stream_next: <http://nxg.me.uk/norman/> <http://xmlns.com/foaf/0.1/knows> _:r1319914503r13273r3 get_stream_next: orig_statement=0x10181ebb0(7) statement=0x10181ebb0(7) get_stream_next: <http://nxg.me.uk/norman/> <http://xmlns.com/foaf/0.1/mbox> <mailto:[email protected]> Note the same orig_statement and statement being used several times. This _may_ happen only when using the sqlite store -- the in-memory and hashes stores seem to produce different {orig_,}statement each time. This Additional Information: I'm filing this as an API bug, rather than a documentation bug, but feel free to change it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2011-10-29 19:30 normang New Issue ====================================================================== _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
