Re: self contains no data

On 09/12/2012 05:31 AM, Tim Brody wrote:
> Hi,
>
> A minimal test-case would be ideal!

Tryin'; I just can't make anything isolated break!

> If I was trying to debug this I would look for a place where it reliably
> seg-faults, work out which Perl objects are going out of scope, then
> finding where those objects first appear.
>
> I know the findnodes() code is quite complex, so that would seem like an
> obvious place to look for problems.
>
> Otherwise, are you removing children from within a loop over
> findnodes()/childNodes() ? Does the seg fault go away if you collect up
> the nodes to remove then remove them outside of your loop scope?

unfortunately somewhat more complex: there is surgery
on some descendents of the nodes that I get from findnodes.

I did further experimentation with a tree-walk that I can run
before/after various events to try to see when things break.
The closest I can get to "reproducible" crashes when I access
a certain node whose children have apparently been mishandled.

I did find something curious.  So, XML::LibXML nodes are
references to integers.  I don't know if those numbers "mean"
anything --- in ancient times, they were constant, and
you could test node equality by $$a == $$b.
At some point (an update related to thread safety?),
they're no longer constant, and there's a specific
method $a->isSameNode($b).  Would be interested in the back-story.

At any rate, printing out the dereferenced integer while walking
the tree gives me nice 8-digit numbers like 54824480...
until the broken node which has 12 digits (249739024344)
and then I get a segfault before any of the Node methods
can tell me anything about the node!

It's a clue... I suppose that number doesn't correspond
to any real libxml2 node, but why would I have gotten a
reference to it as the child of an seemingly valid node?

Thanks for your suggestions;
bruce

> /Tim.
>
> On Tue, 2012-09-11 at 11:26 -0400, Bruce Miller wrote:
>> A bit of followup to the problem described below.
>>
>> The data corruption seems to be occurring when
>>    * some XML data is found by childNodes, or findnodes, or...
>>    * that data is modified, particularly with things like removeChild
>>    * the data goes out of scope.
>> Presumably Perl is doing cleanup, and
>> either expecting non-null data, or freeing things
>> that have already been freed, or...?
>>
>> I'm guessing that some operations aren't clearing
>> all the fields they should during modification,
>> or not correctly adjusting reference counts for garbage collection.
>>
>> I can write my code to dance around a bit more
>> and seemingly avoid segfaults, but that doesn't
>> really fix the problem.
>>
>> However, I'm not sure how to proceed to find the
>> actual problem. Any hints?
>>
>> Thanks;
>> bruce
>>
>> On 09/09/2012 10:45 PM, Bruce Miller wrote:
>>> Hi gang;
>>>      After a long and productive, mostly uneventful, period of XML crunching
>>> -- Thanks, in part, to your code & support! ---
>>> I've started to see a number of segfaults occurring
>>> in connection (sometimes) with a message along the lines of
>>>      XML::LibXML::Node::nodeType -- self contains no data
>>>
>>> This happens typically after long & complex document
>>> construction & manipulation, so it's hard to pinpoint
>>> what exactly happened.
>>>
>>> My de-segfaulting skills have gotten quite rusty, and I was never so
>>> good with XS, so I can only guess how to interpret what it
>>> means that INT2PTR has given null.
>>>
>>> I've gotten a reference to an int that is no longer
>>> a valid indicator of a libxml2 Node object !?!?!
>>> How would I have done that?
>>>
>>> I realize that I noone can debug from the information
>>> I've given, and it's hard for me to send a reproducible case;
>>> but can anyone suggest places to start looking?
>>> Is there some sort of tree-walk or validation I can
>>> do to try to determine when this invalid thing might
>>> have come into existence?
>>>
>>> FWIW, I suspect that the problem is showing up now
>>> because the evolution of my code is exercising
>>> XML::LibXML differently, rather than a new bug in LibXML.
>>> (also it seems to occur in versions 1.90 and 2.00, maybe earlier?)
>>>
>>> Thanks in advance
>>> bruce
>>> _______________________________________________
>>> Perl-XML mailing list
>>> [email protected]
>>> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>>>
>>
>> _______________________________________________
>> Perl-XML mailing list
>> [email protected]
>> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>

_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs