[Edbrowse-dev] Finding cycles in the tree

[Edbrowse-dev] Finding cycles in the tree

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

A few words about the last push.
Of late we've been seeing more seg faults, very difficult to track down, seeming to involve infinite recursion.
The latest is from this website.
https://www.washingtonpost.com/news/josh-rogin/wp/2017/01/26/the-state-departments-entire-senior-management-team-just-resigned
Without my last push, it waits for a while, until some stack blows up, then seg faults.
The problem is that a node that is already in the tree is being linked to another node in the tree.
The next traversal goes on forever.
So now, when I link A into B, if A has a parent, i.e. A is already in the tree, I give an explanation at db3, and don't make the link.
That fixes the seg fault, and probably the seg fault in other sites.
This leaves some questions however - why is the js trying to do that?
Is it a mistake cause by our imperfect DOM, or did an earlier routine fail and if that had completed then this link would make more sense?
Or is that what is suppose to happen, and I'm suppose to unlink it from its current location and then link it to the new location?
Is there in implicit remove before the link?
I don't know.
Anyways, with this push, the aforementioned website, at debug 3, gives this message.

linkage cycle, cannot link div 1414 into body 198 before div 203, as the child already has parent div 203
Aborting the link, some data may not be rendered.

The push also adds more information at db4, so we can debug, and answer some of the above questions.
You get the edbrowse tree of nodes, and each dynamic link as it is made

Karl Dahlke

Re: [Edbrowse-dev] Finding cycles in the tree

[Kevin Carhart]

I hope to be on the beat more over the next few days.  I know you asked 
about the attributes routines too.  I'll be trying to find out what I can 
find out tonight and tomorrow.
Kevin


  On Thu, 26 Jan 2017, Karl Dahlke wrote:

> A few words about the last push.
> Of late we've been seeing more seg faults, very difficult to track down, seeming to involve infinite recursion.
> The latest is from this website.
> https://www.washingtonpost.com/news/josh-rogin/wp/2017/01/26/the-state-departments-entire-senior-management-team-just-resigned
> Without my last push, it waits for a while, until some stack blows up, then seg faults.
> The problem is that a node that is already in the tree is being linked to another node in the tree.
> The next traversal goes on forever.
> So now, when I link A into B, if A has a parent, i.e. A is already in the tree, I give an explanation at db3, and don't make the link.
> That fixes the seg fault, and probably the seg fault in other sites.
> This leaves some questions however - why is the js trying to do that?
> Is it a mistake cause by our imperfect DOM, or did an earlier routine fail and if that had completed then this link would make more sense?
> Or is that what is suppose to happen, and I'm suppose to unlink it from its current location and then link it to the new location?
> Is there in implicit remove before the link?
> I don't know.
> Anyways, with this push, the aforementioned website, at debug 3, gives this message.
>
> linkage cycle, cannot link div 1414 into body 198 before div 203, as the child already has parent div 203
> Aborting the link, some data may not be rendered.
>
> The push also adds more information at db4, so we can debug, and answer some of the above questions.
> You get the edbrowse tree of nodes, and each dynamic link as it is made
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

Re: [Edbrowse-dev] Finding cycles in the tree

[Kevin Carhart]

What do you think about trying to isolate the cause by going into the 
version control and compiling edbrowse from different moments in time, til 
you hone in on the point of transition where Raw Story or Washington Post 
did work before a patch and no longer worked after it?




> A few words about the last push.
> Of late we've been seeing more seg faults, very difficult to track down, seeming to involve infinite recursion.
> The latest is from this website.
> https://www.washingtonpost.com/news/josh-rogin/wp/2017/01/26/the-state-departments-entire-senior-management-team-just-resigned
> Without my last push, it waits for a while, until some stack blows up, then seg faults.
> The problem is that a node that is already in the tree is being linked to another node in the tree.
> The next traversal goes on forever.
> So now, when I link A into B, if A has a parent, i.e. A is already in the tree, I give an explanation at db3, and don't make the link.
> That fixes the seg fault, and probably the seg fault in other sites.
> This leaves some questions however - why is the js trying to do that?
> Is it a mistake cause by our imperfect DOM, or did an earlier routine fail and if that had completed then this link would make more sense?
> Or is that what is suppose to happen, and I'm suppose to unlink it from its current location and then link it to the new location?
> Is there in implicit remove before the link?
> I don't know.
> Anyways, with this push, the aforementioned website, at debug 3, gives this message.
>
> linkage cycle, cannot link div 1414 into body 198 before div 203, as the child already has parent div 203
> Aborting the link, some data may not be rendered.
>
> The push also adds more information at db4, so we can debug, and answer some of the above questions.
> You get the edbrowse tree of nodes, and each dynamic link as it is made
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] Finding cycles in the tree

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

> What do you think about trying to isolate the cause by going into the
> version control and compiling edbrowse from different moments in time, til
> you hone in on the point of transition where Raw Story or Washington Post
> did work before a patch and no longer worked after it?

I don't think it would tell us anything.
This problem popped up because we got enough of the js working to move forward, and make the links, whence one of those links does not make a proper tree.
Adam's removeAttribute for example, it works and the js moves forward.
(Speaking of which, I made all the Attribute routines consistent, and hopefully correct.)
It's like turning on the light and seeing the mess.
We wouldn't want to back up, we want to keep moving on.
Delve into a site and find out why that link doesn't assemble a proper tree -
or check the spec again and maybe it says somewhere that I'm suppose to unlink the node from where it was, if it was already in the tree, then put it in the new place.
db4 and watch all the nodes created from html, and dynamically, and how they put together.
Would be great if we had a site with no js errors, and still the tree problem, then we'd know we were on to something.
But these sites still have lots of js errors, lots of functions that don't run to completion, so who knows.
Maybe we could tell visually from another browser what the tree of nodes is suppose to be.

Karl Dahlke

Re: [Edbrowse-dev] Finding cycles in the tree

[Kevin Carhart]

On Fri, 27 Jan 2017, Karl Dahlke wrote:

>> What do you think about trying to isolate the cause by going into the
>
> I don't think it would tell us anything. This problem popped up because 
> we got enough of the js working to move forward, and make the links,

> hopefully correct.) It's like turning on the light and seeing the mess.

Ahh yes, I take your point on that.  This has happened to me quite a bit. 
You pore over problem 1, fix it, and CONGRATULATIONS!  Your reward is.....
........ problem 2!  A bigger mess.   So it's a good thing, it just 
doesn't feel like one.  You have to bear in mind that the whole thing was 
masked out up until that point and you have now revealed it, not just get 
frustrated by problem 2.