Re: [xml] Segfault freeing doc after replaceNode() in python

On Wed, May 04, 2005 at 05:47:23PM -0500, Brent Hendricks wrote:
The attached script is a copy of the included python test file with two important differences:

1) It uses replaceNode() instead of addChild() to put the 'cut' node 
into the destination document

2) It segfaults :(

My guess is that somehow the cut/replaced node is being freed twice.  If 
I comment out the freeDoc line for either the source or target it stops 
segfaulting (but then of course, leaks memory).

Any ideas?

  Hard to tell from just looking at the code.
  Cut and pasting document subtree is getting a very tricky and error
prone business due to dictionaries, though I think this example uses only
the old APIs which don't use dictionnaries by default.

gdb /usr/bin/python and r confirms the problem:

xmlDictOwns__internal_alias (dict=0xffffffff, str=0x9807388 "bar")
    at dict.c:870
870         pool = dict->strings;
(gdb) where
#0  xmlDictOwns__internal_alias (dict=0xffffffff, str=0x9807388 "bar")
    at dict.c:870
#1  0x0032923f in xmlCtxtCheckName (ctxt=0xbff66c00, name=0x9807388 "bar")
    at debugXML.c:257
#2  0x003294f2 in xmlCtxtGenericNodeCheck (ctxt=0xbff66c00, node=0x980d7f0)
    at debugXML.c:357
#3  0x0032a26f in xmlCtxtDumpAttr (ctxt=0xbff66c00, attr=0x980d7f0)
    at debugXML.c:840
#4  0x0032a290 in xmlCtxtDumpAttrList (ctxt=0xbff66c00, attr=0x980d7f0)
    at debugXML.c:855
#5  0x0032a6c9 in xmlCtxtDumpOneNode (ctxt=0xbff66c00, node=0x97b0a08)
    at debugXML.c:1009
#6  0x0032a7a2 in xmlCtxtDumpNode (ctxt=0xbff66c00, node=0x97b0a08)
    at debugXML.c:1052
#7  0x0032a7e7 in xmlCtxtDumpNodeList (ctxt=0xbff66c00, node=0x97b0a08)
    at debugXML.c:1072
#8  0x0032a7c0 in xmlCtxtDumpNode (ctxt=0xbff66c00, node=0x97b09a8)
    at debugXML.c:1055
#9  0x0032a7e7 in xmlCtxtDumpNodeList (ctxt=0xbff66c00, node=0x97b09a8)
    at debugXML.c:1072
#10 0x0032a7c0 in xmlCtxtDumpNode (ctxt=0xbff66c00, node=0x9803590)
    at debugXML.c:1055
#11 0x0032a7e7 in xmlCtxtDumpNodeList (ctxt=0xbff66c00, node=0x9803590)
    at debugXML.c:1072
#12 0x0032ab90 in xmlCtxtDumpDocument (ctxt=0xbff66c00, doc=0x980d540)
    at debugXML.c:1206
#13 0x0032b23e in xmlDebugCheckDocument__internal_alias (output=0xa6c460,
    doc=0x980d540) at debugXML.c:1561
#14 0x00306b10 in xmlFreeDoc__internal_alias (cur=0x980d540) at tree.c:1136
#15 0x002c32e6 in libxml_xmlFreeDoc (self=0x0, args=0xb7fd140c)
    at libxml2-py.c:13560
#16 0x001c88e1 in PyCFunction_Call () from /usr/lib/
#17 0x001fb4ec in _PyEval_SliceIndex () from /usr/lib/
#18 0x001fc94b in _PyEval_SliceIndex () from /usr/lib/
#19 0x001fd06e in PyEval_EvalCodeEx () from /usr/lib/
#20 0x001fd332 in PyEval_EvalCode () from /usr/lib/
#21 0x002167e7 in PyErr_Display () from /usr/lib/
#22 0x00217912 in PyRun_SimpleFileExFlags () from /usr/lib/
#23 0x00218964 in PyRun_AnyFileExFlags () from /usr/lib/
#24 0x0021d65e in Py_Main () from /usr/lib/
#25 0x080485b2 in main ()

  This is in my debugging environment, but apparently a node refers to a 
deleted dictionnary (dict=0xffffffff means a freed area in libxml2 debug


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]