Last Comment Bug 940025 - Assertion failure: ret == (-3), at jsutil.cpp
: Assertion failure: ret == (-3), at jsutil.cpp
Status: RESOLVED WORKSFORME
: assertion, regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: ARM Linux
: -- normal (vote)
: ---
Assigned To: general
: general
: Jason Orendorff [:jorendorff]
Mentors:
Depends on:
Blocks: jsfunfuzz 912928 savesource
  Show dependency treegraph
 
Reported: 2013-11-18 14:14 PST by Gary Kwong [:gkw] [:nth10sd]
Modified: 2013-11-19 20:19 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
stack (1.73 KB, text/plain)
2013-11-18 14:14 PST, Gary Kwong [:gkw] [:nth10sd]
no flags Details

Description User image Gary Kwong [:gkw] [:nth10sd] 2013-11-18 14:14:26 PST
Created attachment 8334102 [details]
stack

We hit OOM on ARM when we set the following parameters:

resource.setrlimit(resource.RLIMIT_CORE, (500000000, -1))
resource.setrlimit(resource.RLIMIT_AS, (400000000, -1))

and try to run a testcase that tries to allocate a bunch of memory followed by more stuff. Sometimes the following assertion gets hit:

Assertion failure: ret == (-3), at jsutil.cpp

Jesse helped me out here. Is the assert at http://hg.mozilla.org/mozilla-central/annotate/f2adb62d07eb/js/src/jsutil.cpp#l64 - " JS_ASSERT(ret == Z_DATA_ERROR); " valid?

Compressor::~Compressor()
{
    int ret = deflateEnd(&zs);
    if (ret != Z_OK) {
        // If we finished early, we can get a Z_DATA_ERROR.
        JS_ASSERT(ret == Z_DATA_ERROR);
        JS_ASSERT(uInt(zs.next_in - inp) < inplen || !zs.avail_out);
    }
}

We probably can get around this particular testcase by bumping resource.RLIMIT_AS to 500000000 instead, but I'm not sure if this is really fixing the problem.
Comment 1 User image :Benjamin Peterson 2013-11-18 14:19:59 PST
I believe the assert is valid if zlib is following its documentation. :P Can you possibly get a debugger in there and see what the value of |ret| actually is?
Comment 2 User image Gary Kwong [:gkw] [:nth10sd] 2013-11-19 13:11:38 PST
No, apparently the value of ret is optimized out and this seems to require --enable-optimize --enable-debug.
Comment 3 User image :Benjamin Peterson 2013-11-19 13:31:09 PST
You can't |printf| or something?
Comment 4 User image Gary Kwong [:gkw] [:nth10sd] 2013-11-19 13:35:37 PST
> You can't |printf| or something?

It shows <optimized out> in gdb, unless you mean recompiling the shell to printf the ret value just before the assert is hit?
Comment 5 User image :Benjamin Peterson 2013-11-19 13:44:08 PST
(In reply to Gary Kwong [:gkw] [:nth10sd] (yes, still catching up on bugmail) from comment #4)
> > You can't |printf| or something?
> 
> It shows <optimized out> in gdb, unless you mean recompiling the shell to
> printf the ret value just before the assert is hit?

That is what I meant.
Comment 6 User image Gary Kwong [:gkw] [:nth10sd] 2013-11-19 20:19:23 PST
Hmmm, I tried going back to the same rev and reproducing this, but am unable to. I guess I'll ponder again when I hit this the next time.

Note You need to log in before you can comment on or make changes to this bug.