All right, here is the full trace and heap state. I have also
uncommented DEBUG in rdf_storage_virtuoso.c
Looks like the origin is in Virtodbc.
$ valgrind --tool=memcheck --num-callers=50 --leak-check=full rdfproc -t
"dsn='Virtuoso',user=*,password=*" -s virtuoso
http://www.3top.com/graph/fscharf remove
http://dbpedia.org/resource/Apple
http://www.3top.com/entity/ranked_in_category
http://www.3top.com/category/530/asian-fruits
==4710== Memcheck, a memory error detector
==4710== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4710== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for
copyright info
==4710== Command: rdfproc -t dsn='Virtuoso',user=*,password=* -s
virtuoso http://www.3top.com/graph/fscharf remove
http://dbpedia.org/resource/Apple
http://www.3top.com/entity/ranked_in_category
http://www.3top.com/category/530/asian-fruits
==4710==
librdf_storage_virtuoso_init
librdf_storage_virtuoso_init_connections
librdf_storage_virtuoso_open
librdf_storage_virtuoso_context_remove_statement
librdf_storage_virtuoso_connection
SQL: >>sparql define output:format '_JAVA_' delete from graph iri(??)
{`iri(??)` `iri(??)` `bif:__rdf_long_from_batch_params(??,??,??)`}<<
librdf_storage_virtuoso_release_handle 0x6eac3b0
rdfproc: removed triple from the graph
librdf_storage_virtuoso_close
librdf_storage_virtuoso_transaction_rollback
librdf_storage_virtuoso_sync
librdf_storage_virtuoso_terminate
librdf_storage_virtuoso_finish_connections
==4710== Invalid free() / delete / delete[] / realloc()
==4710== at 0x4C2BDEC: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4710== by 0x80A9F18: librdf_storage_virtuoso_terminate
(rdf_storage_virtuoso.c:1199)
==4710== by 0x50B21DA: librdf_free_storage (rdf_storage.c:723)
==4710== by 0x403CBB: main (rdfproc.c:1597)
==4710== Address 0x6eab860 is 0 bytes inside a block of size 34 free'd
==4710== at 0x4C2BDEC: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4710== by 0x80AC9ED:
librdf_storage_virtuoso_context_remove_statement
(rdf_storage_virtuoso.c:2089)
==4710== by 0x4056A8: main (rdfproc.c:1280)
==4710==
==4710==
==4710== HEAP SUMMARY:
==4710== in use at exit: 148,416 bytes in 3,255 blocks
==4710== total heap usage: 5,487 allocs, 2,233 frees, 787,600 bytes
allocated
==4710==
==4710== 24 bytes in 1 blocks are possibly lost in loss record 598 of 749
==4710== at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4710== by 0x9A01ADC: dk_alloc_reserve_malloc (Dkernel.c:5430)
==4710== by 0x99ECE2C: dk_alloc_box (Dkbox.c:191)
==4710== by 0x99EDB82: box_dv_short_string (Dkbox.c:1427)
==4710== by 0x9A019B8: PrpcConnect1 (Dkernel.c:4458)
==4710== by 0x99CCEEC: internal_sql_connect (CLIsql1.c:900)
==4710== by 0x99EA5ED: virtodbc__SQLDriverConnect.isra.1 (CLIsql3.c:767)
==4710== by 0x82C49C5: ???
==4710== by 0x80AA285: ???
==4710== by 0x80AC840: ???
==4710== by 0x4056A8: main (rdfproc.c:1280)
==4710==
==4710== 224 (40 direct, 184 indirect) bytes in 1 blocks are definitely
lost in loss record 681 of 749
==4710== at 0x4C2CC70: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4710== by 0x50AC045: librdf_new_hash_from_hash (rdf_hash.c:482)
==4710== by 0x50B24D7: librdf_new_storage_with_options
(rdf_storage.c:579)
==4710== by 0x4035EC: main (rdfproc.c:683)
==4710==
==4710== 1,698 (72 direct, 1,626 indirect) bytes in 1 blocks are
definitely lost in loss record 737 of 749
==4710== at 0x4C2CC70: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4710== by 0x82FE02E: ???
==4710== by 0x82FE30E: ???
==4710== by 0x82BE8BC: ???
==4710== by 0x82C496D: ???
==4710== by 0x80AA285: ???
==4710== by 0x80AC840: ???
==4710== by 0x4056A8: main (rdfproc.c:1280)
==4710==
==4710== 4,232 bytes in 1 blocks are definitely lost in loss record 745
of 749
==4710== at 0x4C2CC70: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4710== by 0x80AB945: ???
==4710== by 0x50B2346: librdf_new_storage_from_factory
(rdf_storage.c:698)
==4710== by 0x4035EC: main (rdfproc.c:683)
==4710==
==4710== LEAK SUMMARY:
==4710== definitely lost: 4,344 bytes in 3 blocks
==4710== indirectly lost: 1,810 bytes in 101 blocks
==4710== possibly lost: 24 bytes in 1 blocks
==4710== still reachable: 142,238 bytes in 3,150 blocks
==4710== suppressed: 0 bytes in 0 blocks
==4710== Reachable blocks (those to which a pointer was found) are not
shown.
==4710== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4710==
==4710== For counts of detected and suppressed errors, rerun with: -v
==4710== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 1 from 1)
Thanks for your help
Francois
Le 2/20/15 7:36 AM, Michael Stahl a écrit :
On 13.02.2015 19:49, François Scharffe wrote:
I get errors when trying to remove triples, both through the python
bindings or using rdfproc.
rdfproc gives the following output:
rdfproc: removed triple from the graph
*** Error in `rdfproc': double free or corruption (!prev):
0x00000000016d5130 ***
Aborted (core dumped)
The triple is actually removed.
I use Redland with Virtuoso through unixODBC.
this is definitely a bug somewhere, and you can use valgrind to track
down where exactly. you need to install debuginfo packages, or rebuild
things with debug enabled until valgrind produces useful output (with
line numbers).
valgrind --tool=memcheck --num-callers=50 rdfproc ...
_______________________________________________
redland-dev mailing list
[email protected]
http://lists.librdf.org/mailman/listinfo/redland-dev
_______________________________________________
redland-dev mailing list
[email protected]
http://lists.librdf.org/mailman/listinfo/redland-dev
