edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] memory error
Date: Sun, 23 Feb 2014 23:16:06 +0000	[thread overview]
Message-ID: <20140223231606.GE15819@toaster.adamthompson.me.uk> (raw)
In-Reply-To: <20140123175711.eklhad@comcast.net>

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.

  reply	other threads:[~2014-02-23 23:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-23 22:57 Karl Dahlke
2014-02-23 23:16 ` Adam Thompson [this message]
2014-02-23 23:53   ` Chris Brannon
2014-02-24 10:25     ` Adam Thompson
2014-02-24  1:47 Karl Dahlke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140223231606.GE15819@toaster.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).