From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Finding cycles in the tree
Date: Thu, 26 Jan 2017 21:19:01 -0500 [thread overview]
Message-ID: <20170026211901.eklhad@comcast.net> (raw)
[-- 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
next reply other threads:[~2017-01-27 2:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 2:19 Karl Dahlke [this message]
2017-01-27 6:29 ` Kevin Carhart
2017-01-27 6:37 ` Kevin Carhart
2017-01-27 10:09 ` Karl Dahlke
2017-01-29 2:24 ` Kevin Carhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170026211901.eklhad@comcast.net \
--to=eklhad@comcast.net \
--cc=Edbrowse-dev@lists.the-brannons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).