Closed Bug 1333470 Opened 3 years ago Closed 3 years ago

Crash in shutdownhang | libsystem_kernel.dylib@0x19c86 when two background threads are busy running nsAStreamCopier::Run

Categories

(Core :: Gecko Profiler, defect, critical)

Unspecified
macOS
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1333384
Tracking Status
firefox-esr45 --- affected
firefox51 --- affected
firefox52 --- affected
firefox53 --- affected
firefox54 --- affected

People

(Reporter: ehsan, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-3a6a1caa-dd8a-4290-bc84-2d5ca2170121.
=============================================================

See threads 25 and 26 in this crash.

As far as I can tell, these threads start pegging the CPU at 100% each as soon as I capture a profile when the capture gets stuck on waiting for XUL symbols currently on Nightly.  I have let these threads (sometimes I get one and sometimes I get two) run for hours and they never finish.  Eventually during the shutdown we get killed like this.

Another example:

bp-dd306b15-0c3d-4d05-9ebf-d6b772170124
I think Andrea landed a fix over in bug 1333384.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1333384
What's your Gecko profiler addon version? Versions between 2.0.0 and <2.0.13 had a bug where the DOM Worker would go into an infinite loop because my JS code was buggy.
Oh. bkelly is right, I hadn't made the connection to the profiler.
(In reply to Markus Stange [:mstange] from comment #2)
> What's your Gecko profiler addon version? Versions between 2.0.0 and <2.0.13
> had a bug where the DOM Worker would go into an infinite loop because my JS
> code was buggy.

2.0.18.
(In reply to Markus Stange [:mstange] from comment #2)
> What's your Gecko profiler addon version? Versions between 2.0.0 and <2.0.13
> had a bug where the DOM Worker would go into an infinite loop because my JS
> code was buggy.

Wait... What were the symptoms you were seeing?  We should never get stuck in an infinite loop running JS!
Flags: needinfo?(mstange)
My JS was getting stuck in a loop of its own. The addon launches a worker thread (with chrome privileges) to parse the symbol dump, and for some inputs, the JS code was basically equivalent to a "while (true) {}", so the worker never completed. I don't know if it was killed after a timeout. I didn't see a slow script dialog. Maybe because the worker had chrome privileges.
I fixed the bug in https://github.com/devtools-html/Gecko-Profiler-Addon/commit/865f1b093efabfc8359e4ef17d232466310c007c .
In any case, you're running 2.0.18 and your stacks clearly point to bug 1333384, so the addon bug is completely unrelated.
Flags: needinfo?(mstange)
Yeah, I was definitely seeing bug 1333384.  I was asking this because if you indeed found a case where the worker wouldn't terminate, that's a bug in our worker implementation.  (Not getting the slow script dialog is expected.)
Crash volume for signature 'shutdownhang | libsystem_kernel.dylib@0x19c86':
 - nightly (version 54): 8 crashes from 2017-01-23.
 - aurora  (version 53): 3 crashes from 2017-01-23.
 - beta    (version 52): 39 crashes from 2017-01-23.
 - release (version 51): 173 crashes from 2017-01-16.
 - esr     (version 45): 128 crashes from 2016-08-03.

Crash volume on the last weeks (Week N is from 01-30 to 02-05):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       8
 - aurora        1
 - beta         22
 - release      98       0
 - esr          26      21      26      16       8      14       6

Affected platform: Mac OS X

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #89
 - aurora  #157
 - beta    #231
 - release #129
 - esr     #1280
You need to log in before you can comment on or make changes to this bug.