https://tbpl.mozilla.org/php/getParsedLog.php?id=19205595&tree=Firefox Rev3 Fedora 12 mozilla-central pgo test mochitest-3 on 2013-01-28 11:03:04 PST for push 80fed51ae074 slave: talos-r3-fed-003 55 INFO TEST-START | /tests/dom/media/tests/mochitest/test_peerConnection_basicAudio.html TEST-UNEXPECTED-FAIL | /tests/dom/media/tests/mochitest/test_peerConnection_basicAudio.html | Exited with code 11 during test run INFO | automation.py | Application ran for: 0:00:07.207483 INFO | automation.py | Reading PID log: /tmp/tmpq7LwXipidlog Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux/1359371383/firefox-21.0a1.en-US.linux-i686.crashreporter-symbols.zip PROCESS-CRASH | /tests/dom/media/tests/mochitest/test_peerConnection_basicAudio.html | application crashed [@ linked_ptr<CSF::CC_Device>::depart()] Crash dump filename: /tmp/tmpSjT0Gj/minidumps/28c94a85-02f5-70b0-079ba65b-227788da.dmp Operating system: Linux 0.0.0 Linux 220.127.116.11-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST 2009 i686 CPU: x86 GenuineInte family 6 model 23 stepping 10 2 CPUs Crash reason: SIGSEGV Crash address: 0x8d243c89 Thread 0 (crashed) 0 libxul.so!linked_ptr<CSF::CC_Device>::depart() [linked_ptr.h:80fed51ae074 : 67 + 0x2] eip = 0x0291bab6 esp = 0xbfed8930 ebp = 0xbfed8948 ebx = 0x02fe190c esi = 0x8d243c89 edi = 0xbfed8968 eax = 0x8d243c89 ecx = 0xbfed896c edx = 0xbfed89ec efl = 0x00010202 Found by: given as instruction pointer in context 1 libxul.so!CSF::CallControlManagerImpl::onDeviceEvent(ccapi_device_event_e, linked_ptr<CSF::CC_Device>, linked_ptr<CSF::CC_DeviceInfo>) [linked_ptr.h:80fed51ae074 : 84 + 0x4] eip = 0x0291bbae esp = 0xbfed8950 ebp = 0xbfed8978 ebx = 0x02fe190c esi = 0xbfed8960 edi = 0xbfed8968 Found by: call frame info 2 libxul.so!CSF::CC_SIPCCService::notifyDeviceEventObservers(ccapi_device_event_e, linked_ptr<CSF::CC_Device>, linked_ptr<CSF::CC_DeviceInfo>) [CC_SIPCCService.cpp:80fed51ae074 : 721 + 0x20] eip = 0x01ed830f esp = 0xbfed8980 ebp = 0xbfed89e8 ebx = 0x02fe190c esi = 0xbfed8a10 edi = 0xbfed8a18 Found by: call frame info 3 libxul.so!CSF::CC_SIPCCService::onDeviceEvent(ccapi_device_event_e, unsigned int, cc_device_info_t_*) [CC_SIPCCService.cpp:80fed51ae074 : 607 + 0x22] eip = 0x01ed8560 esp = 0xbfed89f0 ebp = 0xbfed8a48 ebx = 0x02fe190c esi = 0xbfed8a10 edi = 0xbfed8a18 Found by: call frame info 4 libxul.so!ccsnap_gen_deviceEvent [ccapi_snapshot.c:80fed51ae074 : 409 + 0x12] eip = 0x01ee8adc esp = 0xbfed8a50 ebp = 0xbfed8a98 ebx = 0x02fe190c esi = 0x9e2fd470 edi = 0x00000000 Found by: call frame info 5 libxul.so!parse_setup_properties [ccapi_config.c:80fed51ae074 : 59 + 0x13] eip = 0x01ee4edb esp = 0xbfed8aa0 ebp = 0xbfed8ab8 ebx = 0x02fe190c esi = 0x00000000 edi = 0xa2cfb3cc Found by: call frame info 6 libxul.so!CCAPI_Start_response [ccapi_config.c:80fed51ae074 : 41 + 0x20] eip = 0x01ee4fa0 esp = 0xbfed8ac0 ebp = 0xbfed8b08 ebx = 0x02fe190c esi = 0x00000000 edi = 0xa2cfb3cc
That hasn't happened before so it would be good to know which latest landing has caused this regression.
Keywords: regression, regressionwindow-wanted
That's true of every single intermittent-failure - with one failure, we know the odds of hitting this are 1/∞, so we could find where it was introduced by retriggering ∞ times on every push between that one and the one where the peerconnection tests got turned on.
I haven't said now. But yes, if it doesn't reproduce yet we will have to wait.
Crash Signature: [@ linked_ptr<CSF::CC_Device>::depart()]
Assigning to Adam as this seems like it may be related or the same as the other SIPCC startup race causing basicaudio failures
Assignee: nobody → adam
Priority: -- → P1
Just this morning, I found myself wondering why we're not seeing the race I describe in the third paragraph of Bug 823056 comment 34 being lost in other ways than the one that leaves CCApp spinning in depart. There should be variations on the corruption of the circular linked list. This looks like one of the variations I would have expected to pop up. I agree with Randell that this almost certainly has the same root cause as bug 823056. Because it has a different signature when the race is lost in this direction, I'll leave it open and mark it as depending on 823056 (rather than marking it a dupe). I think we can close them at the same time once the race is fixed.
Depends on: 823056
Sorry, must have been a misclick, the two bug suggestions are next to each other in TBPL's annotated summary.
As mentioned before, this is the same as bug 823056, which has been patched and landed on m-c. I'm closing this bug as a duplicate now.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 823056
You need to log in before you can comment on or make changes to this bug.