960644 - Crash with glibc abort when decompiling function

Status: RESOLVED DUPLICATE of bug 952984

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 324e2cba1029 (run with --fuzzing-safe):


function f() {
    function f1(other) {
        eval("gc(); h = g1");
        try {
            for(var i=0; i<20; i++) 1;
            assertEq(typeof other, "function");
        } catch(e) {
            assertEq(typeof other !== "function", true);
            assertEq(e instanceof TypeError, true);
        }
    }
    f1(3);
    f1(null);
    f1({});
    f1(Math.abs);
    f1(g2);
}
f.toString().replace(/[\r\n]/g, '');

Comment 1

[Christian Holler (:decoder)]

This only reproduces in an optimized build for me. It does look very unhealthy too:

Program received signal SIGABRT, Aborted.
0x00007ffff6c07425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6c07425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6c0ab8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6c4539e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff6cdb817 in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff6cdb7e0 in __stack_chk_fail () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00000000006d47b9 in StrReplaceRegexpRemove (cx=<optimized out>, str=..., re=..., rval=...) at js/src/jsstr.cpp:2768
#6  0x00000000006f6c40 in StrReplaceRegExp (cx=0x13c2930, rdata=..., rval=...) at js/src/jsstr.cpp:2791
#7  0x00000000006f86f7 in str_replace_regexp (rdata=..., cx=0x13c2930, args=...) at js/src/jsstr.cpp:2831
#8  js::str_replace (cx=0x13c2930, argc=2, vp=0x1467a40) at js/src/jsstr.cpp:3023
#9  0x000000000075aa12 in CallJSNative (args=..., native=0x6f7af0 <js::str_replace(JSContext*, unsigned int, JS::Value*)>, cx=0x13c2930) at js/src/jscntxtinlines.h:220
#10 js::Invoke (cx=0x13c2930, args=..., construct=<optimized out>) at js/src/vm/Interpreter.cpp:465
#11 0x000000000074e078 in Interpret (cx=0x13c2930, state=...) at js/src/vm/Interpreter.cpp:2610
#12 0x0000000000758b73 in js::RunScript (cx=0x13c2930, state=...) at js/src/vm/Interpreter.cpp:422
#13 0x0000000000758e85 in RunScript (state=..., cx=0x13c2930) at js/src/vm/Interpreter.cpp:389
#14 js::ExecuteKernel (cx=0x13c2930, script=..., scopeChainArg=..., thisv=..., type=<optimized out>, evalInFrame=..., result=0x0) at js/src/vm/Interpreter.cpp:619
#15 0x000000000075912f in js::Execute (cx=0x13c2930, script=..., scopeChainArg=..., rval=0x0) at js/src/vm/Interpreter.cpp:656
#16 0x0000000000690be4 in JS_ExecuteScript (cx=0x13c2930, objArg=0x7ffff683d060, scriptArg=<optimized out>, rval=0x0) at js/src/jsapi.cpp:4761
#17 0x000000000040e743 in RunFile (compileOnly=false, file=0x13cfc50, filename=<optimized out>, obj=..., cx=0x13c2930) at js/src/shell/js.cpp:403
#18 Process (cx=0x13c2930, obj_=<optimized out>, filename=<optimized out>, forceTTY=<optimized out>) at js/src/shell/js.cpp:536
#19 0x0000000000411970 in ProcessArgs (op=0x7fffffffdb10, obj_=0x7ffff683d060, cx=0x13c2930) at js/src/shell/js.cpp:5622
#20 Shell (envp=<optimized out>, op=0x7fffffffdb10, cx=0x13c2930) at js/src/shell/js.cpp:5667
#21 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:5954

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Error: Failed to compile specified revision 324e2cba1029 (maybe try another?)

Comment 3

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, failed due to error: Error: Failed to compile specified revision 324e2cba1029 (maybe try another?)

Comment 4

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This seems only broken in non-threadsafe builds, however changesets broke compilation between d633e3ff2013 and bcbe93f41547, and the original revision was in the middle.

I added a suppression for this broken range, but by the end of the range where compilation started working again (bcbe93f41547), the bug was no longer reproducing. Hence comment 4.

I'd say, maybe mark this WFM? And maybe land the test eventually?

Comment 6

[Christian Holler (:decoder)]

First of all, this did reproduce on threadsafe builds too (actually, the fuzzer machine running the threadsafe builds initially found this).

I am not comfortable with closing this as WFM because the bug is very fragile and might easily have been broken by a few changes to the tree, while it would for sure be a security bug.

CCing some devs that can maybe tell more.

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> the bug is very fragile and might easily have been broken by a few changes to the tree,
> while it would for sure be a security bug.

This does seem to be a possibility.

Comment 8

[Hannes Verschore [:h4writer]]

Could this have been bug 952984 ?

Comment 9

[Hannes Verschore [:h4writer]]

Is this bug still present? I think it was bug 952984, but I cannot confirm or deny, since I cannot reproduce the testcase. If it is, we can close this as duplicate.

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

decoder should be a better person to retest this a final time.

Comment 11

[Hannes Verschore [:h4writer]]

(In reply to Gary Kwong [:gkw] [:nth10sd] catching up on email/bugmail from comment #10)
> decoder should be a better person to retest this a final time.

Oh sorry. Since you replied last, I assumed you found and reported this bug. I now see it was actually decoder. Thanks

Comment 12

[Christian Holler (:decoder)]

I cannot reproduce this anymore. I'm fine with marking this as a dup if Hannes is saying that this was likely bug 952984.