Closed Bug 786987 Opened 12 years ago Closed 12 years ago

Intermittent mochitest-4 Shutdown, Talos | application timed out after 330 seconds with no output, under mozilla::dom::workers::RuntimeService::Cleanup()

Categories

(Core :: DOM: Workers, defect)

Product:
Core
Component:
DOM: Workers
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20
Tracking Flags:
Tracking Status
firefox17 --- affected
firefox18 --- affected
firefox19 --- affected
firefox-esr17 --- affected

People

(Reporter: emorley, Unassigned)

References

Details

(Keywords: hang, intermittent-failure) 

+++ This bug was initially created as a clone of Bug #614146 +++

Rev3 WINNT 5.1 mozilla-inbound debug test mochitests-4/5 on 2012-08-30 00:11:02 PDT for push 9659ba8dfa67

slave: talos-r3-xp-075

https://tbpl.mozilla.org/php/getParsedLog.php?id=14829479&tree=Mozilla-Inbound

{
TEST-UNEXPECTED-FAIL | Shutdown | application timed out after 330 seconds with no output
args: ['C:\\talos-slave\\test\\build\\bin\\screenshot.exe', 'c:\\docume~1\\cltbld\\locals~1\\temp\\mozilla-test-fail_fqfsg8']
INFO | automation.py | Application ran for: 0:21:30.704000
INFO | automation.py | Reading PID log: c:\docume~1\cltbld\locals~1\temp\tmpen7wrkpidlog
==> process 3452 launched child process 508
INFO | automation.py | Checking for orphan process with PID: 508
Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-debug/1346307024/firefox-18.0a1.en-US.win32.crashreporter-symbols.zip
PROCESS-CRASH | Shutdown | application crashed (minidump found)
Crash dump filename: c:\docume~1\cltbld\locals~1\temp\tmpkazeam\minidumps\6dd8895c-773b-4551-b726-277f2ab17c12.dmp
Operating system: Windows NT
                  5.1.2600 Service Pack 2
CPU: x86
     GenuineIntel family 6 model 23 stepping 10
     2 CPUs

Crash reason:  EXCEPTION_ACCESS_VIOLATION_WRITE
Crash address: 0x0

Thread 27 (crashed)
 0  crashinjectdll.dll!CrashingThread(void *) [crashinjectdll.cpp:9659ba8dfa67 : 17 + 0x0]
    eip = 0x04d21019   esp = 0x073fffb8   ebp = 0x073fffec   ebx = 0x00000000
    esi = 0x071ff7f0   edi = 0x00000001   eax = 0x00000000   ecx = 0x073fffb0
    edx = 0x7c90eb94   efl = 0x00010246
    Found by: given as instruction pointer in context
 1  kernel32.dll + 0xb50a
    eip = 0x7c80b50b   esp = 0x073fffbc   ebp = 0x073fffec
    Found by: stack scanning

Thread 0
 0  ntdll.dll + 0xeb94
    eip = 0x7c90eb94   esp = 0x0012f71c   ebp = 0x0012f780   ebx = 0xffffffff
    esi = 0x00000750   edi = 0x00000000   eax = 0x00000006   ecx = 0x00000000
    edx = 0x00000000   efl = 0x00200246
    Found by: given as instruction pointer in context
 1  kernel32.dll + 0x2541
    eip = 0x7c802542   esp = 0x0012f788   ebp = 0x0012f794
    Found by: previous frame's frame pointer
 2  nspr4.dll!_PR_MD_WAIT_CV [w95cv.c:9659ba8dfa67 : 248 + 0xd]
    eip = 0x1001d109   esp = 0x0012f79c   ebp = 0x03c60b2c
    Found by: previous frame's frame pointer
 3  nspr4.dll!_PR_WaitCondVar [prucv.c:9659ba8dfa67 : 172 + 0x27]
    eip = 0x1001856c   esp = 0x0012f7b8   ebp = 0x0012f808
    Found by: stack scanning
 4  nspr4.dll!PR_Wait [prmon.c:9659ba8dfa67 : 152 + 0x19]
    eip = 0x100182d3   esp = 0x0012f7d0   ebp = 0x0012f808
    Found by: stack scanning
 5  xul.dll!mozilla::ReentrantMonitor::Wait(unsigned int) [BlockingResourceBase.cpp:9659ba8dfa67 : 313 + 0x1a]
    eip = 0x02d112cc   esp = 0x0012f7ec   ebp = 0x0012f808
    Found by: stack scanning
 6  xul.dll!nsEventQueue::GetEvent(bool,nsIRunnable * *) [nsEventQueue.cpp:9659ba8dfa67 : 51 + 0x9]
    eip = 0x02d5b2d3   esp = 0x0012f810   ebp = 0x0012f824
    Found by: call frame info
 7  xul.dll!nsThread::ProcessNextEvent(bool,bool *) [nsThread.cpp:9659ba8dfa67 : 605 + 0x2d]
    eip = 0x02d5d4af   esp = 0x0012f82c   ebp = 0x0012f858
    Found by: call frame info
 8  xul.dll!NS_ProcessNextEvent_P(nsIThread *,bool) [nsThreadUtils.cpp:9659ba8dfa67 : 220 + 0xc]
    eip = 0x02d0f001   esp = 0x0012f860   ebp = 0x0012f86c
    Found by: call frame info
 9  xul.dll!mozilla::dom::workers::RuntimeService::Cleanup() [RuntimeService.cpp:9659ba8dfa67 : 1017 + 0xc]
    eip = 0x023851f6   esp = 0x0012f874   ebp = 0x0012faac
    Found by: call frame info
10  xul.dll!mozilla::dom::workers::RuntimeService::Observe(nsISupports *,char const *,wchar_t const *) [RuntimeService.cpp:9659ba8dfa67 : 1238 + 0x7]
    eip = 0x023855bf   esp = 0x0012fab4   ebp = 0x0012fab4
    Found by: call frame info
}
Component: DOM → DOM: Workers
Ben, this has become quite a bit more frequent of late, please may you take a look? :-)
Flags: needinfo?(bent.mozilla)
We've tried recording this many times and haven't had any success thus far... I'll talk with Kyle and see if he has cycles to try again.
Flags: needinfo?(bent.mozilla)
Whiteboard: [orange]
Also talos:
https://tbpl.mozilla.org/php/getParsedLog.php?id=17344001&tree=Mozilla-Inbound

{
Thread 0 (crashed)
 0  linux-gate.so + 0x424
    eip = 0x005d3424   esp = 0xbf8db7f0   ebp = 0xbf8db858   ebx = 0xb76f0a88
    esi = 0x00000000   edi = 0x0000005d   eax = 0xfffffffc   ecx = 0x00000080
    edx = 0x0000005d   efl = 0x00000286
    Found by: given as instruction pointer in context
 1  libnspr4.so!PR_Wait [ptsynch.c : 582 + 0x11]
    eip = 0x0049d0c7   esp = 0xbf8db860   ebp = 0xbf8db898
    Found by: previous frame's frame pointer
 2  libxul.so!mozilla::ReentrantMonitor::Wait(unsigned int) [ReentrantMonitor.h : 89 + 0x9]
    eip = 0x0134eec7   esp = 0xbf8db8a0   ebp = 0xbf8db8b8   ebx = 0x02a505cc
    esi = 0xb76fb12c   edi = 0xbf8db950
    Found by: call frame info
 3  libxul.so!nsEventQueue::GetEvent(bool, nsIRunnable**) [ReentrantMonitor.h : 192 + 0x9]
    eip = 0x01e79e1b   esp = 0xbf8db8c0   ebp = 0xbf8db8f8   ebx = 0x02a505cc
    esi = 0xb76fb12c   edi = 0xbf8db950
    Found by: call frame info
 4  libxul.so!nsThread::ProcessNextEvent(bool, bool*) [nsThread.cpp : 619 + 0xe]
    eip = 0x01e7b3c2   esp = 0xbf8db900   ebp = 0xbf8db978   ebx = 0x02a505cc
    esi = 0xb76fb100   edi = 0x00000000
    Found by: call frame info
 5  libxul.so!NS_ProcessNextEvent_P(nsIThread*, bool) [nsThreadUtils.cpp : 221 + 0x11]
    eip = 0x01e49c84   esp = 0xbf8db980   ebp = 0xbf8db9a8   ebx = 0x02a505cc
    esi = 0x00000001   edi = 0xab179b64
    Found by: call frame info
 6  libxul.so!mozilla::dom::workers::RuntimeService::Cleanup() [RuntimeService.cpp : 1148 + 0xe]
    eip = 0x018226b6   esp = 0xbf8db9b0   ebp = 0xbf8dbc18   ebx = 0x02a505cc
    esi = 0xab179b60   edi = 0xab179b64
    Found by: call frame info
 7  libxul.so!mozilla::dom::workers::RuntimeService::Observe(nsISupports*, char const*, unsigned short const*) [RuntimeService.cpp : 1370 + 0x8]
    eip = 0x018227df   esp = 0xbf8dbc20   ebp = 0xbf8dbc48   ebx = 0x02a505cc
    esi = 0xab179b60   edi = 0x02676f9b
    Found by: call frame info
 8  libxul.so!nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*) [nsObserverList.cpp : 99 + 0xc]
    eip = 0x01e58f74   esp = 0xbf8dbc50   ebp = 0xbf8dbc78   ebx = 0x02a505cc
    esi = 0x00000001   edi = 0x02676f9b
    Found by: call frame info
 9  libxul.so!nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) [nsObserverService.cpp : 161 + 0xa]
    eip = 0x01e59324   esp = 0xbf8dbc80   ebp = 0xbf8dbcb8   ebx = 0x02a505cc
    esi = 0x02676f9b   edi = 0x00000000
}
Summary: Intermittent mochitest-4 Shutdown | application timed out after 330 seconds with no output, under mozilla::dom::workers::RuntimeService::Cleanup() → Intermittent mochitest-4 Shutdown, Talos | application timed out after 330 seconds with no output, under mozilla::dom::workers::RuntimeService::Cleanup()
Ben, this failure isn't able to be starred on TBPL and as such is quite a pain for non-sheriffs to identify (eg results in unnecessary confusion/retriggers on Try), and is also still fairly high up the toporanges list. Please can you take a look?
Flags: needinfo?(bent.mozilla)
(In reply to Ed Morley [UTC+0; email:edmorley@moco] from comment #97)
> Ben, this has become quite a bit more frequent of late, please may you take
> a look? :-)

(In reply to ben turner [:bent] from comment #99)
> We've tried recording this many times and haven't had any success thus
> far... I'll talk with Kyle and see if he has cycles to try again.

(In reply to Ed Morley [UTC+0; email:edmorley@moco] from comment #159)
> Ben, this failure isn't able to be starred on TBPL and as such is quite a
> pain for non-sheriffs to identify (eg results in unnecessary
> confusion/retriggers on Try), and is also still fairly high up the
> toporanges list. Please can you take a look?

Ben, any luck speaking to Kyle? Between this and the many other Workers/IndexedDB intermittent failure bugs that don't seem to be going anywhere, the sheriffs are being driven up the wall somewhat...

Thank you :-)
(In reply to Ed Morley [UTC+0; email:edmorley@moco] from comment #171)
> Ben, any luck speaking to Kyle?

The replay machine was broken a while back but I hear khuey has fixed it. Not sure when he will be able to try recording this again, we're all very busy working toward the B2G deadline.
Flags: needinfo?(bent.mozilla)
Should be fixed by bug 823953 \o/ :-)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Well we'll see.  It's possible that there's more than one cause of this.
Yeah, it can be, but lets give it a couple more days to make sure first :-)
You need to log in before you can comment on or make changes to this bug.