On Wed, Feb 19, 2014 at 09:34:22AM -0800, Chris Brannon wrote: > Adam Thompson <[email protected]> writes: > > > I'm not sure if that's even possible at the moment given the way some of the > > functions work. I'd hope that what happens when we destroy the context is > > that > > the context-linked roots also go away (which'd make sense). > > They don't go away. I just verified that with gdb.
Ugh, that's actually really annoying. > I'm starting to see a possible fix, I think. > In javaSessionFail, do not call freeJavaContext at all. > Add a new variable to cw: cw->jss_saved. > Now javaSessionFail looks like this: > cw->jss_saved = cw->jss; > cw->jss = NULL; > > Now we have two cases to consider. > 1. Spidermonkey ran out of memory while parsing the page, or > 2. Spidermonkey ran out of memory when handling a JS event like onclick. > > For case 1, when we've finished parsing the page, > call freeJavaContext(cw->jss_saved) if cw->jss_saved is not NULL. > Set cw->jss_saved to NULL so we don't double-free. > I think we can do this at the end of parsePage. There will be no > stack-allocated JS roots at this point. Yep, or set a flag in cw like js_failed and leave jss as non-null, adding the relevant checks. > > It's going to be a lot messier for case 2, I think. Can we just do the > "free-if-saved" check after each call to handlerGo? Probably. > > BTW, freeJavaContext also has a bug. Yep, I pushed a fix for this one earlier today. Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
