Closed Bug 1134393 Opened 9 years ago Closed 3 years ago

Intermittent test_blob_worker_xhr_read_slice.html | timeout and application crashed [@ mozilla::dom::workers::WorkerThread::SetWorker] after "Assertion failure: !mOtherThreadsDispatchingViaEventTarget (XPCOM Dispatch hapenning at the same time our thread"

Categories

(Core :: DOM: Workers, defect, P5)

Product:
Core
Component:
DOM: Workers
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: RyanVM, Unassigned)

References

Details

(Keywords: assertion, crash, intermittent-failure)

Attachments

(1 file)

stack
128.41 KB, text/plain
Details 
11:35:19 INFO - 237 INFO TEST-START | dom/indexedDB/test/test_blob_worker_xhr_read_slice.html
11:35:19 INFO - [Child 774] WARNING: NS_ENSURE_TRUE(node) failed: file ../../../gecko/layout/base/nsDocumentViewer.cpp, line 3523
11:35:19 INFO - [Child 774] WARNING: NS_ENSURE_TRUE(node) failed: file ../../../gecko/layout/base/nsDocumentViewer.cpp, line 3523
11:35:19 INFO - [Child 774] WARNING: NS_ENSURE_TRUE(node) failed: file ../../../gecko/layout/base/nsDocumentViewer.cpp, line 3523
11:35:20 INFO - [Child 774] WARNING: Performance Entry buffer size maximum reached!: file ../../../gecko/dom/base/nsPerformance.cpp, line 560
11:35:23 INFO - [Child 774] WARNING: NS_ENSURE_TRUE(node) failed: file ../../../gecko/layout/base/nsDocumentViewer.cpp, line 3523
11:35:23 INFO - [Child 774] WARNING: NS_ENSURE_TRUE(node) failed: file ../../../gecko/layout/base/nsDocumentViewer.cpp, line 3523
11:35:23 INFO - [Child 774] WARNING: NS_ENSURE_TRUE(node) failed: file ../../../gecko/layout/base/nsDocumentViewer.cpp, line 3523
11:35:24 INFO - [Child 774] WARNING: Unable to printf the requested string due to error.: file ../../../gecko/ipc/chromium/src/base/string_util.cc, line 427
11:35:25 INFO - [Child 774] WARNING: A runnable was posted to a worker that is already shutting down!: file ../../../gecko/dom/workers/WorkerPrivate.cpp, line 2344
11:35:26 INFO - 238 INFO TEST-OK | dom/indexedDB/test/test_blob_worker_xhr_read_slice.html | took 7296ms
11:35:27 INFO - [Child 774] WARNING: Performance Entry buffer size maximum reached!: file ../../../gecko/dom/base/nsPerformance.cpp, line 560
11:35:29 INFO - ############ ErrorPage.js
11:35:29 INFO - [Parent 702] WARNING: RemoveObserver() called for unregistered observer: file ../../gecko/hal/Hal.cpp, line 205
11:35:29 INFO - [Parent 702] WARNING: RemoveObserver() called for unregistered observer: file ../../gecko/hal/Hal.cpp, line 205
11:35:29 INFO - [Parent 702] WARNING: NS_ENSURE_TRUE(mCallback) failed: file ../../../gecko/dom/base/nsFrameMessageManager.cpp, line 674
11:35:29 INFO - JavaScript error: chrome://specialpowers/content/SpecialPowersObserver.js, line 103: NS_ERROR_NOT_INITIALIZED: Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMessageSender.sendAsyncMessage]
11:43:22 INFO - DeviceRunner TEST-UNEXPECTED-FAIL | dom/indexedDB/test/test_blob_worker_xhr_read_slice.html | application timed out after 450.0 seconds with no output
11:43:22 WARNING - PROCESS-CRASH | dom/indexedDB/test/test_blob_worker_xhr_read_slice.html | application crashed [@ mozilla::dom::workers::WorkerThread::SetWorker]
11:43:22 INFO - Crash dump filename: /tmp/tmpz_bqFw/597cb1f0-7144-7e0c-42739c66-69e71d9a.dmp
11:43:22 INFO - Operating system: Android
11:43:22 INFO - 0.0.0 Linux 2.6.29-g41a03df #22 Thu Jun 26 10:59:09 CST 2014 armv7l Android/full/generic:4.0.4.0.4.0.4/OPENMASTER/eng.cltbld.20150218.114730:eng/test-keys
11:43:22 INFO - CPU: arm
11:43:22 INFO - 0 CPUs
11:43:22 INFO - Crash reason: SIGSEGV
11:43:22 INFO - Crash address: 0x0
11:43:22 INFO - Thread 17 (crashed)
11:43:22 INFO - 0 libxul.so!mozilla::dom::workers::WorkerThread::SetWorker [WorkerThread.cpp:7f4925153bd9 : 126 + 0x2]
11:43:22 INFO - r4 = 0x442c4cc0 r5 = 0x505ffb90 r6 = 0x00000000 r7 = 0x00000000
11:43:22 INFO - r8 = 0x442c4cd0 r9 = 0x00000000 r10 = 0x442c4cc0 fp = 0x505ffc20
11:43:22 INFO - sp = 0x505ffb88 lr = 0x415d615f pc = 0x415eb03e
11:43:22 INFO - Found by: given as instruction pointer in context
11:43:22 INFO - 1 libxul.so!mozilla::dom::workers::WorkerPrivate::SetThread [WorkerPrivate.cpp:7f4925153bd9 : 6179 + 0xd]
11:43:22 INFO - r4 = 0x44a4a400 r5 = 0x00000000 r6 = 0x505ffbbc r7 = 0x505ffbc8
11:43:22 INFO - r8 = 0x44a4a67c r9 = 0x00000000 r10 = 0x442c4cc0 fp = 0x505ffc20
11:43:22 INFO - sp = 0x505ffbb8 pc = 0x415f5691
11:43:22 INFO - Found by: call frame info
11:43:22 INFO - 2 libxul.so!WorkerThreadPrimaryRunnable::Run [RuntimeService.cpp:7f4925153bd9 : 2700 + 0x7]
11:43:22 INFO - r4 = 0x455415c0 r5 = 0x505ffc74 r6 = 0x4578c000 r7 = 0x505ffce0
11:43:22 INFO - r8 = 0x4555e250 r9 = 0x4578c000 r10 = 0x45790000 fp = 0x505ffc20
11:43:22 INFO - sp = 0x505ffbf0 pc = 0x415d24c7
11:43:22 INFO - Found by: call frame info
11:43:22 INFO - 3 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp:7f4925153bd9 : 855 + 0x9]
11:43:22 INFO - r4 = 0x442c4d04 r5 = 0x00000000 r6 = 0x442c4cc0 r7 = 0x505ffde8
11:43:22 INFO - r8 = 0x505ffddc r9 = 0x00000001 r10 = 0x505ffe27 fp = 0x00000000
11:43:22 INFO - sp = 0x505ffdb8 pc = 0x4086c235
11:43:22 INFO - Found by: call frame info
11:43:22 INFO - 4 libxul.so!NS_ProcessNextEvent [nsThreadUtils.cpp:7f4925153bd9 : 265 + 0xd]
11:43:22 INFO - r4 = 0x442c4cc0 r5 = 0x00000001 r6 = 0x4419cb68 r7 = 0x4419cb60
11:43:22 INFO - r8 = 0x00000000 r9 = 0x00000000 r10 = 0x442c4cd0 fp = 0x00000001
11:43:22 INFO - sp = 0x505ffe20 pc = 0x4088082d
11:43:22 INFO - Found by: call frame info
11:43:22 INFO - 5 libxul.so!mozilla::ipc::MessagePumpForNonMainThreads::Run [MessagePump.cpp:7f4925153bd9 : 368 + 0x7]
11:43:22 INFO - r4 = 0x4419cb50 r5 = 0x452c8cc0 r6 = 0x4419cb68 r7 = 0x4419cb60
11:43:22 INFO - r8 = 0x00000000 r9 = 0x00000000 r10 = 0x442c4cd0 fp = 0x00000001
11:43:22 INFO - sp = 0x505ffe38 pc = 0x40a3c15f
11:43:22 INFO - Found by: call frame info
11:43:22 INFO - 6 libxul.so!MessageLoop::RunInternal [message_loop.cc:7f4925153bd9 : 233 + 0xf]
11:43:22 INFO - r4 = 0x452c8cc0 r5 = 0x505ffe98 r6 = 0x505ffea0 r7 = 0x452c8cc0
11:43:22 INFO - r8 = 0x00000001 r9 = 0x00000000 r10 = 0x442c4cd0 fp = 0x00000001
11:43:22 INFO - sp = 0x505ffe60 pc = 0x40a2b199
11:43:22 INFO - Found by: call frame info 

11:45:25 INFO - 02-18 19:35:27.227 F/MOZ_Assert( 774): Assertion failure: !mOtherThreadsDispatchingViaEventTarget (XPCOM Dispatch hapenning at the same time our thread is being unset! This should not be possible!), at ../../../gecko/dom/workers/WorkerThread.cpp:128
Flags: needinfo?(nsm.nikhil)
Not sure why I'm being ni?ed. bent?
Flags: needinfo?(nsm.nikhil) → needinfo?(bent.mozilla)
Attached file stack — 

    
    

    
  
Ah so the race is:

T1: RemoteBlobImpl::Destroy() -> WorkerThread::Dispatch()
T2: WorkerThread::SetWorker()

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
khuey, I finally figured out the race in comment 22, but haven't had time to fix it yet. Maybe something that could be done here is to add a blob counter that lives on a WorkerPrivate, and not let the worker shut down until the last blob is destroyed (similar to features but without the extra overhead of callbacks). What do you think?
Flags: needinfo?(bent.mozilla) → needinfo?(khuey)

    
    

    
  
(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #26)
> khuey, I finally figured out the race in comment 22, but haven't had time to
> fix it yet. Maybe something that could be done here is to add a blob counter
> that lives on a WorkerPrivate, and not let the worker shut down until the
> last blob is destroyed (similar to features but without the extra overhead
> of callbacks). What do you think?

Why not just use features?  They're not *that* high overhead.
Flags: needinfo?(khuey) → needinfo?(bent.mozilla)

    
    

    
      
  

    
    

    
  
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #27)
> (In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #26)
> Why not just use features?  They're not *that* high overhead.

Well, in theory you can create a lot of blobs, and sticking those in the features array and then calling a no-op Notify() on all of them seems wasteful. And removing a feature has bad perf impact on a big array like that... If you end up using features maybe change the array to a hash? Not sure, I haven't really thought about this too much.
Flags: needinfo?(bent.mozilla)

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Priority: P3 → P5

    
    

    
  
This is not happening since a long time now.


Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: