[Edbrowse-dev] in compartment

[Edbrowse-dev] in compartment

[Karl Dahlke]

Well don't worry bout indenting for the moment, not vital;
and thanks again for all your help.

Karl Dahlke

Re: [Edbrowse-dev] in compartment

[Adam Thompson]

On Wed, Feb 19, 2014 at 08:39:38PM -0500, Karl Dahlke wrote:
> Well don't worry bout indenting for the moment, not vital;
> and thanks again for all your help.

That's ok, if I can just repeat the segfault I had last night (basically js ran
out of memory but didn't trigger javaSessionFail and then something in the smjs machinary blew up)
then I think we'll have got a handle on many of the problems. Unfortunately I
can't seem to reproduce this particular segfault.

Thanks for adding the memory hogging script to jsrt as well.
I think it behaves as expected (basically causes lots of errors to be thrown
with no segfault).
In addition, after running the memory hogging script timers still work,
but the unload functions don't.

Cheers,
Adam.

[Edbrowse-dev] in compartment

[Karl Dahlke]

Maybe ... in javaSessionFail just print and set a flag,
Then return because of the error condition.
The calling function might then return because of the error,
and so on, unwinding the stack all the way back to html.
So there was an error but cw->jss is still there.
in the SwitchCompartment macro,
if js is dead then return, as we do today,
but if it is still there and the abort flag is set then destroy context and set jss = null and return.

Everything would unwind and free properly,
and the js context would go away, perhaps on the next call.
Maybe that would keep things from becoming a mess.

Karl Dahlke

Re: [Edbrowse-dev] in compartment

[Adam Thompson]

On Wed, Feb 19, 2014 at 03:39:12PM -0500, Karl Dahlke wrote:
> Maybe ... in javaSessionFail just print and set a flag,
> Then return because of the error condition.
> The calling function might then return because of the error,
> and so on, unwinding the stack all the way back to html.
> So there was an error but cw->jss is still there.

Sounds like a plan.

> in the SwitchCompartment macro,
> if js is dead then return, as we do today,
> but if it is still there and the abort flag is set then destroy context and set jss = null and return.

Hmm, I wonder if we have any nested SWITCH_COMPARTMENT calls which'd break this.
I quite like Chris's idea of leaving the destruction of the context until we're
sure the stack has unwound correctly.
> 
> Everything would unwind and free properly,
> and the js context would go away, perhaps on the next call.
> Maybe that would keep things from becoming a mess.

Hopefully. I'm going to implement this tonight to see how it turns out.

Would it be possible for the memory-hogging program to be added to jsrt as a
button (as you previously mentioned)
as that should give a repeatable test for this.
The existing way of browsing it then something else which uses javascript
triggers the unable to create window object error rather than a javascript
session failure.

Cheers,
Adam.

Re: [Edbrowse-dev] in compartment

[Adam Thompson]

On Wed, Feb 19, 2014 at 09:09:36PM +0000, Adam Thompson wrote:
> On Wed, Feb 19, 2014 at 03:39:12PM -0500, Karl Dahlke wrote:
> > Maybe ... in javaSessionFail just print and set a flag,
> > Then return because of the error condition.
> > The calling function might then return because of the error,
> > and so on, unwinding the stack all the way back to html.
> > So there was an error but cw->jss is still there.

Implemented the setting of the flag (cw->js_fail)
and now have a freeJavaContext call in browseCurrentBuffer if js has died.
This fixes the segfault you reported earlier (at least in my test).
However, I've now run into another out of memory condition which isn't triggering javaSessionFail etc which I need to look into.

I've pushed my latest progress, though I know I need to re-indent things once
all this is sorted.

Cheers,
Adam.