From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2001:558:fe21:29:69:252:207:39; helo=resqmta-ch2-07v.sys.comcast.net; envelope-from=eklhad@comcast.net; receiver= Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 1AB5C7A6F6 for ; Mon, 7 Aug 2017 05:42:52 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id ehNLdcgx2rUTyehNbdVhqd; Mon, 07 Aug 2017 12:43:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1502109811; bh=vYDf4YRyUgbifNEyY9AnZtlqfFX8Apr20CnucXS/3oM=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=eFxT7OW1isU7+cJMXhr9gmqonmj0l7Ov4cCIL3J0IaHJpTHHygpbhwCHhu2jCeJ2v sPRJ5BvZHNXxfNMd1X7zNO1tQAJVnIyX/nCQxOl/xNvmgSjl2jkmHZal+7GkpH7CW8 KnG64PHuaaOLMUheucxjDdOv0Drb+GzQtiKsKwOpdoH08lhu+t80IzIEY2onq27Kzx eafQswoIoyAbMjZch1CsqBjQ/WV0vgLKEQaHv5N3Kc5KPcig5BkihcTtbHXfUX0Gkq y3M0kHvcZ15AIWcjRdJG2OtUiJF9gv4CkEG1HyDcGj6ggHtQaGsevtDnpqCvhVLPSW BE6DXag9Claxw== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-12v.sys.comcast.net with SMTP id ehNadF7HACzjwehNbdBnQp; Mon, 07 Aug 2017 12:43:31 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.0+ Date: Mon, 07 Aug 2017 08:43:30 -0400 Message-ID: <20170707084330.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-792735 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPvbc7kuEOm7oYiZ6bNPsTfeeOxd+nwWaUDFa6Uu/R0YClLOSpaoLsEtoXqi4WMn8lEUKGfw54m2CnuzMm7e3YTz027h3yp1AXPzdX/Fm+iyJp7NW07i b8X24xAZLUKgBqkAvfnieYR8isRX7aTNmrjGajSSRQzWgtaXIs8GdeEB Subject: [Edbrowse-dev] Browser Lockup 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: Mon, 07 Aug 2017 12:58:43 -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-792735 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is a story of my wife Wendy. She was surfing the net when her browser locked up with an error = message on the screen and a repeated warning playing through the audio. It said her computer was infected, and she could get help by calling = this number. Well she runs a mac, and they don't get viruses very often. It can happen, but not very often. No, it seemed to be web page specific. She runs chrome. We poked around for a while and realized it was stuck fast, and the = only way out was a force quit. This is like the quit signal in unix, or control alt delete in windows. Chrome was blown out of the water. We brought it back up and it asked if we wanted to resume where we left = off. "Hell no!", that's what caused the problem in the first place. So it came up fine. To be safe I cleared the cache and the internal temp files. She's been browsing since then with no trouble. So I don't think it was a virus in her machine, but rather, a carefully = crafted and malicious web page. This relates to our discussion of 1 or 2 processes. There are many advantages to one process, so many that it will probably = win the day, but the biggest con, as Adam pointed out, is the way js = could monopolize the cpu, whence all of edbrowse is locked up. I wonder though, is this what happened to Chrome? Did the bad web page simply put js in an infinite loop, so there it = sits? I wanted to study it, but I didn't get the url of the page, and it's = probably dynamic anyways, cause they don't want to get caught. We could make our own though, with an infinite js loop, and see how the = various browsers deal with it. It would be nice if there was a flag that duktape checked from time to = time, and if set, duktape would stop execution. This flag would be set by the signal handler for SIGINT. Then we would have a breakout mechanism. I don't think duktape does that, but we have lots of native methods, I = wonder if any of those could watch for this flag and somehow stop = execution. That won't help if the infinite loop is while(true) ; but if it's a complex runaway loop creating nodes or running timers or = innerHTML or such, then we might be able to stop it. Definitely something to think about. Karl Dahlke --nextpart-eb-792735--