Closed Bug 1018372 Opened 11 years ago Closed 11 years ago

Intermittent 408431-1.html, 863929.html | application crashed [@ sipcc::PeerConnectionImpl::CheckThreadInt() const]

Categories

(Core :: WebRTC, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox30 --- unaffected
firefox31 --- unaffected
firefox32 --- affected
firefox-esr24 --- unaffected

People

(Reporter: RyanVM, Assigned: abr)

References

Details

(Keywords: crash, intermittent-failure)

Attachments

(1 file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=40734450&tree=Mozilla-Inbound Rev5 MacOSX Mountain Lion 10.8 mozilla-inbound debug test crashtest on 2014-05-30 08:48:15 PDT for push 9b01df568861 slave: talos-mtnlion-r5-071 08:53:06 WARNING - TEST-UNEXPECTED-FAIL | file:///builds/slave/talos-slave/test/build/tests/reftest/tests/dom/src/offline/crashtests/408431-1.html | Exited with code 1 during test run 08:53:06 INFO - INFO | automation.py | Application ran for: 0:02:25.916917 08:53:06 INFO - INFO | zombiecheck | Reading PID log: /var/folders/st/kwlxg4xn05n8cx4x4j9k91tc00000w/T/tmpuJeEmqpidlog 08:53:21 WARNING - PROCESS-CRASH | file:///builds/slave/talos-slave/test/build/tests/reftest/tests/dom/src/offline/crashtests/408431-1.html | application crashed [@ sipcc::PeerConnectionImpl::CheckThreadInt() const] 08:53:21 INFO - Crash dump filename: /var/folders/st/kwlxg4xn05n8cx4x4j9k91tc00000w/T/tmpaWAivi.mozrunner/minidumps/89D58AA4-4F08-4136-BCCF-81943B5D6CA1.dmp 08:53:21 INFO - Operating system: Mac OS X 08:53:21 INFO - 10.8.0 12A269 08:53:21 INFO - CPU: amd64 08:53:21 INFO - family 6 model 42 stepping 7 08:53:21 INFO - 8 CPUs 08:53:21 INFO - Crash reason: EXC_BAD_ACCESS / 0x0000000d 08:53:21 INFO - Crash address: 0x0 08:53:21 INFO - Thread 0 (crashed) 08:53:21 INFO - 0 XUL!sipcc::PeerConnectionImpl::CheckThreadInt() const [PeerConnectionImpl.h:9b01df568861 : 584 + 0x0] 08:53:21 INFO - rbx = 0x00000001218795d0 r12 = 0x000000010052fa00 08:53:21 INFO - r13 = 0x00007fff5fbfd3c7 r14 = 0x0000000000000000 08:53:21 INFO - r15 = 0x000000010052fb7c rip = 0x0000000101c0f126 08:53:21 INFO - rsp = 0x00007fff5fbfd270 rbp = 0x00007fff5fbfd290 08:53:21 INFO - Found by: given as instruction pointer in context 08:53:21 INFO - 1 XUL!sipcc::PeerConnectionImpl::SetDtlsConnected(bool) [PeerConnectionImpl.h:9b01df568861 : 576 + 0x4] 08:53:21 INFO - rbx = 0x00000001218795d0 r12 = 0x000000010052fa00 08:53:21 INFO - r13 = 0x00007fff5fbfd3c7 r14 = 0x0000000000000000 08:53:21 INFO - r15 = 0x000000010052fb7c rip = 0x0000000101c33456 08:53:21 INFO - rsp = 0x00007fff5fbfd2a0 rbp = 0x00007fff5fbfd2c0 08:53:21 INFO - Found by: call frame info 08:53:21 INFO - 2 XUL!mozilla::runnable_args_m_1<sipcc::PeerConnectionImpl*, tag_nsresult (sipcc::PeerConnectionImpl::*)(bool), bool>::Run() [runnable_utils_generated.h:9b01df568861 : 122 + 0x1e] 08:53:21 INFO - rbx = 0x000000010052faa0 r12 = 0x000000010052fa00 08:53:21 INFO - r13 = 0x00007fff5fbfd3c7 r14 = 0x000000010052fb7c 08:53:21 INFO - r15 = 0x000000010052fb7c rip = 0x0000000101c42176 08:53:21 INFO - rsp = 0x00007fff5fbfd2d0 rbp = 0x00007fff5fbfd2d0 08:53:21 INFO - Found by: call frame info 08:53:21 INFO - 3 XUL!nsThread::ProcessNextEvent(bool, bool*) [nsThread.cpp:9b01df568861 : 766 + 0x5] 08:53:21 INFO - rbx = 0x000000010052faa0 r12 = 0x000000010052fa00 08:53:21 INFO - r13 = 0x00007fff5fbfd3c7 r14 = 0x000000010052fb7c 08:53:21 INFO - r15 = 0x000000010052fb7c rip = 0x00000001014bd9ec 08:53:21 INFO - rsp = 0x00007fff5fbfd2e0 rbp = 0x00007fff5fbfd3b0 08:53:21 INFO - Found by: call frame info 08:53:21 INFO - 4 XUL!NS_ProcessPendingEvents(nsIThread*, unsigned int) [nsThreadUtils.cpp:9b01df568861 : 210 + 0xe] 08:53:21 INFO - rbx = 0x0000000000000000 r12 = 0x000000010052faa0 08:53:21 INFO - r13 = 0x00007fff5fbfd3c7 r14 = 0x0000000000000014 08:53:21 INFO - r15 = 0x00000000000abe17 rip = 0x00000001014286fd 08:53:21 INFO - rsp = 0x00007fff5fbfd3c0 rbp = 0x00007fff5fbfd3f0 08:53:21 INFO - Found by: call frame info 08:53:21 INFO - 5 XUL!nsBaseAppShell::NativeEventCallback() [nsBaseAppShell.cpp:9b01df568861 : 98 + 0xe] 08:53:21 INFO - rbx = 0x000000010c44e980 r12 = 0x0000000000000000 08:53:21 INFO - r13 = 0x0000000107000230 r14 = 0x000000010052faa0 08:53:21 INFO - r15 = 0x000000010c44e900 rip = 0x00000001025da7e7 08:53:21 INFO - rsp = 0x00007fff5fbfd400 rbp = 0x00007fff5fbfd420 08:53:21 INFO - Found by: call frame info 08:53:21 INFO - 6 XUL!nsAppShell::ProcessGeckoEvents(void*) [nsAppShell.mm:9b01df568861 : 284 + 0x7] 08:53:21 INFO - rbx = 0x0000000107009c60 r12 = 0x0000000000000000 08:53:21 INFO - r13 = 0x0000000107000230 r14 = 0x0000000107009c78 08:53:21 INFO - r15 = 0x000000010c44e980 rip = 0x000000010259419f 08:53:21 INFO - rsp = 0x00007fff5fbfd430 rbp = 0x00007fff5fbfd470 08:53:21 INFO - Found by: call frame info
Summary: Intermittent 408431-1.html | application crashed [@ sipcc::PeerConnectionImpl::CheckThreadInt() const] → Intermittent 408431-1.html, 863929.html | application crashed [@ sipcc::PeerConnectionImpl::CheckThreadInt() const]
*sigh* Would have helped if I'd CCed some WebRTC folks, eh?
Assignee: nobody → adam
Status: NEW → ASSIGNED
Comment on attachment 8436041 [details] [diff] [review] Check aThread against mThread in PeerConnectionImpl constructor This patch does nothing to fix the problem -- all it will do is help distinguish between the two possible causes of it. The only things that could cause the assertions in the log would be: 1. the aThread passed into the PCImpl ctor is not the main thread, or 2. The value of mThread is stomped somewhere after the PCImpl is created If the new CheckThread triggers -- that is, if we start seeing these assertions with the PC constructor on the stack -- then we'll know someone is passing bogus information into the constructor. Otherwise, this is a heap corruption issue.
Attachment #8436041 - Flags: review?(rjesup)
Attachment #8436041 - Flags: review?(rjesup) → review+
Whiteboard: [leave-open]
Keywords: leave-open
Whiteboard: [leave-open]
See Also: → 1019533
So this and a raft of related bug all started recently; all tied to the crashtests. We need to narrow down the timeframe for the regression, which should help finding the problem.
I'd put very high odds on this being the same root cause as Bug 1019934. The behavior is 100% consistent with a use-after-free condition.
See Also: → 1019934
Should be fixed by backout.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Why are we reopening these bugs again instead of backing billm out? That seems backwards.
Flags: needinfo?(continuation)
because I'm lazy
Flags: needinfo?(continuation)
Allow me then. Backed out again.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: