From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by hurricane.the-brannons.com (Postfix) with ESMTP id 5CD7978621 for ; Sun, 23 Feb 2014 17:48:13 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id W16V1n0091wpRvQ511nFA1; Mon, 24 Feb 2014 01:47:15 +0000 Received: from eklhad ([107.5.36.150]) by omta18.westchester.pa.mail.comcast.net with comcast id W1nF1n00C3EMmQj3e1nFNd; Mon, 24 Feb 2014 01:47:15 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Sun, 23 Feb 2014 20:47:16 -0500 Message-ID: <20140123204716.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393206435; bh=vmfX+kAcZ+sRwfekVPFsxijaKt+eujMNJy+kleT/7yo=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=gYgmsA2PUYXPGbHAY7vbzt0fiUyHLlZvTZTCWlGLV2jOM9Vpo6nmED/JBp6+LC4ZO EAAnvZ5pandpz7eV3/xR3SEVocQDrubOpZQ1HaJFl2KVevcdhB4we1CDJbhtbvOUAW jJPhKmArRdwgpYngcGZuuLbgCQjMGP0m8yDg4cv5eZP4LSDeqlEQM0Bl7LeKZDVNAd SCSeDfF8FIk0W0f7OLBWq7kGHrs8YSA6AZq0dYBbTyAjEI6Ui5h7IRM3DI0LyBg+AF SGOMAf9Ci9Qb5V7+7XR6wzYUw4fIn1Xs2pZ0n0LZUNv7OUsJZxm67WiQOiXHcKMgRQ rclGLinM11GNQ== Subject: [Edbrowse-dev] memory error X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 01:48:13 -0000 > However, doing things based on the error message (which I think comes from > exceptions, user thrown or otherwise) seems a bit more fragile to me. A) So then what are the odds that "out of memory" would appear in an error message that we really should have continued on from? Like an undefined variable or wrong data type or something like that where we wanted to march on but didn't? Pretty unlikely I'd say, "out of memory" is probably in a message when something bad / unrecoverable happens. So plan A is pretty safe, and minimizes oodles of error messages. B) On the other hand, what might go wrong if we do nothing here, and wait for the next call, which will not get the object it wants and then fail and then we close down javascript? Probably this isn't going to cause trouble either. We might be ok with A or B. It might not matter terribly much. Well as mentioned above, B could generate lots more errors before it figures it out. Maybe harder, during debugging, to see when the problem really started. And I think Chriss is asking if there isn't some situation, somewhere, like maybe: var a = [ 2, 3, 1, 7, 9, 2, 8, 9, ... ooddles of elements and we get a memory error because there isn't room for the whole array, but there might have been room for half the array, and maybe the array just isn't created, and now there's still some memory left for js to do some other things, but js assumes the array is in place, but it's not, and then behaves unpredictably. Not a seg fault, but maybe worse, maybe js sends an incomplete order across the internet to amazon.com. We do need to think about these things, even though they are perhaps quite unlikely. Anyways, if I had to cast a vote I guess I'd say to close down js on "out of memory", to supress all the extra error messages, and to guard against the very unlikely but possible js misfirings that might occur if it bumps up agains the memory limit, even temporarily. Karl Dahlke