[redland-dev] Python: Crash (double-free?) in Model.find_statements()

[René Puls]

Dave,

On Mon, 28 Jun 2004 14:36:15 +0100, Dave Beckett
<dave.beckett at bristol.ac.uk> wrote:
> 
> On Mon, 28 Jun 2004 00:28:26 +0200, René Puls <kianga at gmail.com> wrote:
> 
> > Hi,
> >
> > I'm getting strange crashes and/or error messages when using the
> > find_statements() function in connection with a context. The following
> > Python code triggers the error:
...
> quick answer: you are asking for a statement in a context, but you
> didn't create a context enabled store here:

Now it's my turn to say oops...

I must have left out the context option by accident--my original
Python program which first triggered the crash was much larger, so I
tried to reduce this to a minimal test case. I wrote a new test
program now that should use the correct options, but unfortunately it
still crashes:

--- cut here ---

#!/usr/local/bin/python

import RDF

RDFSyntaxNS = RDF.NS("http://www.w3.org/1999/02/22-rdf-syntax-ns#")

selfNode = RDF.Node(uri_string="http://www.example.com/foo")
coreStorage = RDF.Storage(storage_name="hashes", name="crashtest", 
                         
options_string="new='yes',hash-type='memory',contexts='yes'")
coreModel = RDF.Model(coreStorage)

print "Finding type nodes in context", selfNode
testStatement = RDF.Statement(None, RDFSyntaxNS.type, None)
for statement in coreModel.find_statements(testStatement, context=selfNode):
	print "Statement: ", statement

--- cut here ---

Running this on my OpenBSD box gives the following results:

Finding type nodes in context [http://www.example.com/foo]
python in free(): error: chunk is already free
Abort trap (core dumped)

Here is the gdb backtrace:

#0  0x30933ad in _thread_sys_kill ()
#1  0x30c1c65 in abort ()
#2  0x3096001 in execve ()
#3  0x3096037 in execve ()
#4  0x3096ef7 in execve ()
#5  0x309716b in free ()
#6  0xf8df172 in librdf_free_statement (statement=0x3c213d90)
    at rdf_statement.c:224
#7  0xcb2a202 in _wrap_librdf_free_statement (self=0x0, args=0x3c0321ac)
    at ./Redland_wrap.c:1679
#8  0xb0609e1 in PyCFunction_Call ()
#9  0xb08f912 in call_function ()
#10 0xb08d994 in eval_frame ()
#11 0xb08e8e4 in PyEval_EvalCodeEx ()
#12 0xb0534a5 in function_call ()
#13 0xb0417d9 in PyObject_Call ()
#14 0xb047fbc in instancemethod_call ()
#15 0xb0417d9 in PyObject_Call ()
#16 0xb08f6a0 in PyEval_CallObjectWithKeywords ()
#17 0xb076c77 in slot_tp_del ()
#18 0xb06e640 in subtype_dealloc ()
#19 0xb05e163 in insertdict ()
#20 0xb05e43d in PyDict_SetItem ()
#21 0xb06135e in _PyModule_Clear ()
#22 0xb0a17ff in PyImport_Cleanup ()
#23 0xb0a9bc6 in Py_Finalize ()
#24 0xb0b0b77 in Py_Main ()
#25 0x1c0006e1 in main ()
#26 0x1c0005c1 in ___start ()
#27 0x1c000537 in _start ()
#28 0xcfbf57b0 in ?? ()

To make sure this isn't platform-specific, I compiled Redland under
Mac OS X 10.3.4 and ran my test program there, with a similar result:

Finding type nodes in context [http://www.example.com/foo]
*** malloc[25384]: Deallocation of a pointer not malloced: 0x306530;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug

I tested this using the most recent CVS snapshot (June 28). Hopefully
I didn't make any glaring mistakes this time. ;-)

Kind regards,
René Puls