From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out.smtp-auth.no-ip.com (out.smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id C21E27961D for ; Thu, 26 Jan 2017 22:37:02 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 4F3724CE; Thu, 26 Jan 2017 22:37:48 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id v0R6bl5r025323; Thu, 26 Jan 2017 22:37:47 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id v0R6bk0p025317; Thu, 26 Jan 2017 22:37:47 -0800 Date: Thu, 26 Jan 2017 22:37:46 -0800 (PST) From: Kevin Carhart To: Karl Dahlke cc: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20170026211901.eklhad@comcast.net> Message-ID: References: <20170026211901.eklhad@comcast.net> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Edbrowse-dev] Finding cycles in the tree X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.23 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 06:37:02 -0000 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