1291324 - Hit MOZ_CRASH(Failed to create process uptime thread.) at mozglue/misc/TimeStamp_posix.cpp:296

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 465d150bc8be (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu --enable-simulator=arm, run with --fuzzing-safe):

try {
    function f(x) {
        interruptIf(x == 100);
        f('################' + (x));
    }
    f(0);
} catch (exc) {}
let g = newGlobal();
g.promise = Promise.resolve()



Backtrace:

 received signal SIGSEGV, Segmentation fault.
mozilla::TimeStamp::ComputeProcessUptime () at mozglue/misc/TimeStamp_posix.cpp:296
#0  mozilla::TimeStamp::ComputeProcessUptime () at mozglue/misc/TimeStamp_posix.cpp:296
#1  0x080acbda in mozilla::TimeStamp::ProcessCreation (aIsInconsistent=@0xffffb6cb: false) at mozglue/misc/TimeStamp.cpp:67
#2  0x087eb9d3 in MillisecondsSinceStartup () at js/src/builtin/Promise.cpp:49
#3  0x0880f6cb in js::PromiseObject::create (cx=0xf7948000, executor=..., proto=...) at js/src/builtin/Promise.cpp:143
#4  0x088102b9 in js::PromiseConstructor (cx=0xf7948000, argc=1, vp=0xf3f83158) at js/src/builtin/Promise.cpp:375
#5  0x086c8f41 in js::CallJSNative (cx=0xf7948000, native=0x8810010 <js::PromiseConstructor(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:232
[...]
#28 main (argc=3, argv=0xffffcc94, envp=0xffffcca4) at js/src/shell/js.cpp:7515
eax	0x0	0
ebx	0x8be0ff4	146673652
ecx	0xf7d9c864	-136722332
edx	0x0	0
esi	0xf7d9bdf8	-136725000
edi	0xffffb6cb	-18741
ebp	0xffffb618	4294948376
esp	0xffffb5e0	4294948320
eip	0x80ad453 <mozilla::TimeStamp::ComputeProcessUptime()+179>
=> 0x80ad453 <mozilla::TimeStamp::ComputeProcessUptime()+179>:	movl   $0x0,0x0
   0x80ad45d <mozilla::TimeStamp::ComputeProcessUptime()+189>:	ud2    

I also tried this testcase on a 64-bit debug shell and it got killed by the OOM killer. I don't see this behavior very often so I would suggest to check if there's some memory management handling missing somewhere.

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160721025620" and the hash "ae502e2271f2464d92ef398d7c8c43f835865bd6".
The "bad" changeset has the timestamp "20160721033920" and the hash "efcf012e6cfc24413bea5078650e4528be361205".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ae502e2271f2464d92ef398d7c8c43f835865bd6&tochange=efcf012e6cfc24413bea5078650e4528be361205

Comment 2

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

Till, this seems likely to be related to Promises, so setting needinfo? .

Comment 3

[Till Schneidereit [:till]]

Attachment: Call mozilla::TimeStamp::ProcessCreation in JS_Init to ensure getting Promise timestamps is infallible

Comment 4

[Jon Coppeard (:jonco)]

Comment on attachment 8780527 [details] [diff] [review]
Call mozilla::TimeStamp::ProcessCreation in JS_Init to ensure getting Promise timestamps is infallible

Review of attachment 8780527 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/vm/Initialization.cpp
@@ +78,5 @@
>                 "how do we have live runtimes before JS_Init?");
>  
>      PRMJ_NowInit();
> +    bool ignored;
> +    return mozilla::TimeStamp::ProcessCreation(ignored);

I don't think you mean to return here.

This could use a comment as well to say why we need to do this.

r=me with the return fixed.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6f7383e656d6
Call mozilla::TimeStamp::ProcessCreation in JS_Init to ensure getting Promise timestamps is infallible. r=jonco

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6f7383e656d6

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hello Till, could you please nominate for uplift to Aurora50?

Comment 8

[Till Schneidereit [:till]]

(In reply to Ritu Kothari (:ritu) from comment #7)
> Hello Till, could you please nominate for uplift to Aurora50?

I could, but I don't think it's required, really: this can't happen in the browser as the browser already does an equivalent of this during startup. Let me know if you still think it should be uplifted.

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Till Schneidereit [:till] from comment #8)
> (In reply to Ritu Kothari (:ritu) from comment #7)
> > Hello Till, could you please nominate for uplift to Aurora50?
> 
> I could, but I don't think it's required, really: this can't happen in the
> browser as the browser already does an equivalent of this during startup.
> Let me know if you still think it should be uplifted.

That makes sense, I trust your judgement call since you know this better than I. This will now be a wontfix for Fx50 then.