On Sun, Feb 23, 2014 at 10:41:27AM -0800, Chris Brannon wrote:
> 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.
Sorry that was my fault and comes from (I think)
when javaSessionFail destroyed context.
I think the idea at the time was to put return checks on the
domLink calls, but given the way things work now,
I've just fixed (and pushed the changes to)
domLink to call javaSessionFail and return NULL as I was looking through the
code anyway.
> 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.
Yeah, we should.
> 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();
> }
Looks good. Out of interest are there really cases where the error number
doesn't reflect the out of memory condition but the message does?
Cheers,
Adam.
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
