Closed Bug 835476 Opened 11 years ago Closed 11 years ago

Intermittent test_peerConnection_basicAudio.html | application crashed [@ linked_ptr<CSF::CC_Device>::depart()]

Categories

(Core :: WebRTC, defect, P1)

Product:
Core
Component:
WebRTC
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 823056

People

(Reporter: philor, Assigned: abr)

References

Details

(Keywords: crash, intermittent-failure, regression, Whiteboard: [webrtc][blocking-webrtc+])

Crash Data

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 2.6.31.5-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
Whiteboard: [webrtc][blocking-webrtc+]
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
Ed: The log in comment 5 isn't this problem; it's Bug 833557.
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
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.