From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <chris@the-brannons.com>
Received: from localhost (unknown [IPv6:2602:47:d673:8e00:12bf:48ff:fe7c:5584])
 by hurricane.the-brannons.com (Postfix) with ESMTPSA id E75FB78539
 for <edbrowse-dev@lists.the-brannons.com>;
 Sun, 23 Feb 2014 10:42:25 -0800 (PST)
From: Chris Brannon <chris@the-brannons.com>
To: edbrowse-dev@lists.the-brannons.com
Date: Sun, 23 Feb 2014 10:41:27 -0800
Message-ID: <877g8l659k.fsf@mushroom.PK5001Z>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: [Edbrowse-dev] out of memory errors
X-BeenThere: edbrowse-dev@lists.the-brannons.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Edbrowse Development List <edbrowse-dev.lists.the-brannons.com>
List-Unsubscribe: <http://lists.the-brannons.com/mailman/options/edbrowse-dev>, 
 <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=unsubscribe>
List-Archive: <http://lists.the-brannons.com/mailman/private/edbrowse-dev/>
List-Post: <mailto:edbrowse-dev@lists.the-brannons.com>
List-Help: <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=help>
List-Subscribe: <http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev>, 
 <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=subscribe>
X-List-Received-Date: Sun, 23 Feb 2014 18:42:26 -0000

I'm seeing unhandled out-of-memory conditions in domLink and in
handlerSet.  One of these is eventually ending in a segfault.  I can't
tell which one.

Example from jsdom.cpp, line 1522:
				if (JS_DefineProperty(cw->jss->jcx, owner,
						  idname, vv, NULL, NULL, attr) == JS_FALSE)
return NULL;

The failed domLink calls produce hundreds of "out of memory" messages.
We're doing error checking and returning NULL on error, but
javaSessionFail is never called.
So how do you all want to fix it?  Should I just add javaSessionFail()
to the error legs?  I'm willing to write the patch today.

handlerSet is a little more complicated, because it calls
JS_CompileFunction, which can fail for lots of reasons such as a syntax
error.  We're not doing any error checking there at all, but we should
at least try to catch the out of memory condition.
So I wonder about adding the call to javaSessionFail(); to
my_ErrorReporter directly:

	if (report && report->errorNumber == JSMSG_OUT_OF_MEMORY ||
	    message && strstr(message, "out of memory")) {
		i_puts(MSG_JavaMemError);
		javaSessionFail();
}

-- Chris