From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 1DB6877FF6 for ; Sat, 15 Jul 2017 10:03:07 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id WQTRdpFV7XwHwWQU4d4dZg; Sat, 15 Jul 2017 17:04:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1500138240; bh=zqXgF57U/E2Q2xKwhyZQ0BA22Bdws8Qj7wTsA+9ZgsY=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=nsA01aW/Wv7eagVYqKJ26a9bwJySin6aR2zdqlWtsgjKNP7OItY97o0tm5gqBi7KL HmDyV8+wO3gdyk9C2Sbs05xupzcNM29e42M4fV+2S1bdTds5xaZDYeY2pQdENy70mG KcIAoAEXzM/kCVh1TX11YtPoGMirLNrIMvGaqaW6WQ/kUGW2gsTGn4RjNSG3tMWQ6f dM24+KYouRQotI5/ppdylh6578Gq84y5aCde8sgrtVzYUHm6Qz+zZ+/1yRn5pw7YuD Vme1oFGlJnkuMRlXKC+2Y2qFDLlqJr5oA83LzJY5Z4YYMYyDvM4/Iv+FWBYJ3L7DQY DhW4g3cREOHkw== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-09v.sys.comcast.net with SMTP id WQU4d162SqjGuWQU4dntbA; Sat, 15 Jul 2017 17:04:00 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.0x Date: Sat, 15 Jul 2017 13:03:59 -0400 Message-ID: <20170615130359.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-103605 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfE6fl/yK5PgjESlQ82kywz2jL2Eg36XXGrwiGpo6DxvRd0EWfJpoByHyOb4ctji1w/7YDlUhKV6o6CHqHue0/92g7syYcjnsIKDTdViqQRBIDQzzVWJQ ZAbK0lFFD57SwuJBouc0Ce2qPyp9BjU4FWMx9nubjf3I8KhuWGCT+uNT Subject: [Edbrowse-dev] Garbage Collection and Boom X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 17:03:07 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-103605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, this is a long explanation of what I think is happening, and a = reason for the increased fragility of duktape over moz. On the duktape branch, look at jseng-duk.c. At line 1696, just before the break command, add in this line. It's for playing, so I don't really want to push it to github. {const char *gc =3D getenv("GC"); if(gc && *gc) duk_gc(jcx, 0); } Under the control of an environment variable, I can force duktape to do = garbage collection after each script runs. If gc contributes to a seg fault, then it is more reproducible, and not = at the random whim of whenever gc decides to run on its own. So now, we have this test program. hello world It's basically the same script run twice. It creates some nodes, but never links them under document, so at some = point gc will throw them away. I had to create the nodes inside a function, because outside a = function, all variables are global, even variables in blocks are = global, and are immune to gc, so that's why I wrote it this way. If gc doesn't run, this program browses just fine. Try it, without GC, or with export GC=3D Next, set GC=3D1 and browse again. The js process crashes. After the first script runs, duktape throws those nodes away, but aha, = side effects go over to the edbrowse process. It tries to do something with those nodes, gets and sets properties = etc, thinking the nodes are valid. After all, why would real-world javascript create nodes only to throw = them away? Well in this test program edbrowse makes js calls using object pointers = that have been thrown away. This is very reproducible, at least for me. GC=3D browse works fine GC=3D1 browse crash As mentioned before, I had to create the nodes inside a function, so = they would not be global, so gc would throw them away. The following program works with or without gc. hello world So why would this bother us in the real world? Because our DOM is not perfect, and a js script rarely runs to the end. It creates nodes, maybe a whole subtree of nodes, but has some kind of = reference error before it can link those nodes under document. The js script could be 200K, so understandable that gc might run when = it is finished, or might not, who knows, but if it does, and those nodes are not linked in properly, they go away, and edbrowse = tries to mess with them as its side effects, and js crashes. I think that's what happens on real websites. This was less of an issue under moz, because, perhaps, it didn't = garbage collect as often, or it tolerated pointers to invalid objects better than duktape, or it messed up in some way that didn't cause a seg fault. In any case the responsibility is ours, though duktape is less = tolerant, and has brought this to light, so we need to get on the stick = and finish our DOM, so that all scripts run to completion, so all nodes = get linked under document, so gc doesn't throw them away, so this = doesn't happen. Yeah well, that's gonna take a long time. What to do in the meantime? The only thing I can think of, and it's crude and heavy handed, is to ignore side effects that result from a script or js handler that = did not run to completion, and even that I'm not sure how to implement. If the function didn't complete, then the nodes it created might not be = linked in, and might not be valid. Another approach is to change my one pass system into a two pass = system, the first performing all the links, and then, if all the nodes do indeed track back up to document, perform = the other operations on those nodes, in a second pass, because we know = they are valid. Jesus! That's not trivial. We're going to keep js as a separate process for a long time, fragile = as it is; at least you don't lose all your edbrowse sessions when it = crashes. You might want to spin off a separate js process for each edbrowse = window, so a crash still allows js to run in other windows, but you = can't do that because we're going to want interwindow communication, so = all js contexts are in the same heap, and in the same process. Here's another problem, our jsrt regression test. We wrote that ourselves, so the script runs to completion. All nodes link to document and there shouldn't be a problem, but there = is. It runs with GC off, but crashes with GC=3D1. This is showing a problem with edbrowse, but still related to gc, that = I haven't figured out. Are we having fun yet? Karl Dahlke --nextpart-eb-103605--