[Edbrowse-dev] memory error

[Edbrowse-dev] memory error

[Karl Dahlke]

> 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

[Edbrowse-dev] memory error

[Karl Dahlke]

> Out of interest are there really cases where the error number
> doesn't reflect the out of memory condition but the message does?

I think the memory hog test in jsrt is one such.

Karl Dahlke

Re: [Edbrowse-dev] memory error

[Adam Thompson]

On Sun, Feb 23, 2014 at 05:57:11PM -0500, Karl Dahlke wrote:
> > Out of interest are there really cases where the error number
> > doesn't reflect the out of memory condition but the message does?
> 
> I think the memory hog test in jsrt is one such.

That's really annoying.   I've got nothing against taking actions based on the
error number as (if I understand the mechanism correctly)
this is dependant on the type of error.
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.

If we don't do this I wonder if it's really such a bad thing since the
exception will stop the current script (at least if it makes it to our error
reporter), and then js will fail on the next call to one of our functions which uses javaSessionFail anyway.
As far as I can tell from the way mozjs behaves,
the worst that'll happen is the user'll see a bunch of out of memory errors
until something gets called which calls javaSessionFail.
As long as we make sure *all* our js stuff behaves correctly in terms of
handling errors we shouldn't have a problem with this particular condition
causing segfaults I think.

What does everyone else think?

Cheers,
Adam.

Re: [Edbrowse-dev] memory error

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> That's really annoying.   I've got nothing against taking actions based on the
> error number as (if I understand the mechanism correctly)
> this is dependant on the type of error.
> 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.

It does come from an exception.  When out-of-memory is encountered
during script execution, this is converted to a JS exception.  If it
isn't caught, my_ErrorReporter sees it as "uncaught exception: out of
memory".

You're right.  Acting on the error message is fragile, and I don't like
it either.  On the other hand, I like propagating errors to unrelated
parts of the program even less.  Yes, there's a good chance that we'll
catch the error as soon as we call another JSAPI function, but I think
there's also a chance (however slight) that we won't.  E.G., suppose the
script throws the out of memory exception and a bunch of memory gets
reclaimed afterword.  This will probably lead to completely unrelated bugs in
the rest of the JavaScript executed in this context.
So it's a trade-off, and I vote for trying to catch the error as soon as
possible.

-- Chris

Re: [Edbrowse-dev] memory error

[Adam Thompson]

On Sun, Feb 23, 2014 at 03:53:13PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > That's really annoying.   I've got nothing against taking actions based on the
> > error number as (if I understand the mechanism correctly)
> > this is dependant on the type of error.
> > 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.
> 
> It does come from an exception.  When out-of-memory is encountered
> during script execution, this is converted to a JS exception.  If it
> isn't caught, my_ErrorReporter sees it as "uncaught exception: out of
> memory".

Yes, I thought so.

> You're right.  Acting on the error message is fragile, and I don't like
> it either.  On the other hand, I like propagating errors to unrelated
> parts of the program even less.  Yes, there's a good chance that we'll
> catch the error as soon as we call another JSAPI function, but I think
> there's also a chance (however slight) that we won't.  E.G., suppose the
> script throws the out of memory exception and a bunch of memory gets
> reclaimed afterword.  This will probably lead to completely unrelated bugs in
> the rest of the JavaScript executed in this context.

I agree, I just wonder if there's a nicer way to do this.

> So it's a trade-off, and I vote for trying to catch the error as soon as
> possible.

I just added a test for this case in jsrt and it turns out that (as suspected)
the out of memory exception is thrown in one script,
the rest of js can carry on and thus partial arrays etc hang around.
Much as I'd like to think js programmers would handle this, I doubt it.

Cheers,
Adam.