1375459 - netwerk/test/unit/test_backgroundfilesaver.js crashes on Android 4.3 API15+ debug

Status: NEW

(Core :: XPCOM, defect, P3)

Description

[Florian Quèze [:florian]]

Attachment: Test output

The test passes and then crashes at shutdown, I'm attaching the relevant output.

Comment 1

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/74a2ff180838
disable netwerk/test/unit/test_backgroundfilesaver.js on Android 4.3 API15+ debug due to crashes, rs+a=Tomcat

Comment 2

[Florian Quèze [:florian]]

As comment 1 says, I disabled the test which became perma fail when I landed bug 1374282.

It's likely that this change https://hg.mozilla.org/mozilla-central/rev/52e7befb507aa23f93b9214c65758d6d65401293#l12.1 uncovered existing timing issues.

Comment 3

[Paul Bone [:pbone]]

Hi Florian, why is this filed onder JavaScript GC?  If it's not GC specific maybe it should be JavaScript Engine?

Thanks.

Comment 4

[Florian Quèze [:florian]]

(In reply to Paul Bone [:pbone] from comment #3)
> Hi Florian, why is this filed onder JavaScript GC?  If it's not GC specific
> maybe it should be JavaScript Engine?
> 
> Thanks.

Because the log (attachment 8880347 [details]) has lots of error messages related to the GC before the crash.

Comment 5

[Jon Coppeard (:jonco)]

Looks like JSStackFrame still has a pointer to a JSObject after the JS engine has been shut down.  This causes warnings from the GC about cells being live at shutdown.

I'm going to tentatively transfer this to DOM.

Comment 6

[Andrew Overholt [:overholt]]

smaug says he's not sure this is DOM

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Not after shutdown but during shutdown, at least the stack trace.

Is http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/xpcom/base/CycleCollectedJSRuntime.cpp#1107 doing something which one shouldn't do during destroying JSRuntime?

Comment 8

[Jon Coppeard (:jonco)]

This is happening during JSRuntime::destroyRuntime(), and the crash occurs after the end of the shutdown GC in the CycleCollectedJSRuntime::OnGC() callback.

We're clearing a holder which is setting a Heap<T> to nullptr, which triggers the postbarrier.  This attempts to check whether the previous value of the Heap<T> was in the nursery, but the GC has been shutdown at this point and the memory freed.  So we get a SEGV when we try to access it.

The problem is that the holder still had a GC thing pointer in it when we destroyed the runtime.  This is what all the 'found live Cell' errors are about earlier on in the log.  Normally we expect there to be no live pointers into the GC heap when we do the shutdown GC.  So this is a leak somewhere earlier.

One possibility is that the GC should null out live grey roots on shutdown but that could prevent us catching leaks.  Maybe we should do this but check for leaked GC things before we destroy the runtime.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information