Filed by: rvandermeulen [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=4721419&repo=mozilla-central https://autophone.s3.amazonaws.com/v1/task/XIzABw0TSpCEjyYUorCMGw/runs/0/artifacts/public/build/mochitest-webrtc-mochitests-webrtc.ini-1-nexus-5-5-179c0685-3b6f-4afd-89b8-0c291bd1009e.log

Higher Prio because it is a crash bug. For future reference from the raw log (as the parsed logs apparently are not available): 5 INFO TEST-START | dom/media/tests/mochitest/test_dataChannel_basicAudioVideoCombined.html INFO | automation.py | Application ran for: 0:00:33.298900 INFO | zombiecheck | Reading PID log: /tmp/tmpQj1lQipidlog /data/tombstones does not exist; tombstone check skipped mozcrash Copy/paste: /usr/local/bin/minidump_stackwalk /tmp/tmpVii9Qu/7f06b150-ad39-c008-615c59d6-25a08e69.dmp /mozilla/autophone/autophone/builds/aHR0cHM6Ly9xdWV1ZS50YXNrY2x1c3Rlci5uZXQvdjEvdGFzay9YSXpBQncwVFNwQ0VqeVlVb3JDTUd3L3J1bnMvMC9hcnRpZmFjdHMvcHVibGljL2J1aWxkL3RhcmdldC5hcGs=/symbols mozcrash Saved minidump as /tmp/tmp1kJ5GO/7f06b150-ad39-c008-615c59d6-25a08e69.dmp mozcrash Saved app info as /tmp/tmp1kJ5GO/7f06b150-ad39-c008-615c59d6-25a08e69.extra PROCESS-CRASH | dom/media/tests/mochitest/test_dataChannel_basicAudioVideoCombined.html | application crashed [@ RefPtr<mozilla::DataChannelConnection>::operator-> + 0x1e] Crash dump filename: /tmp/tmpVii9Qu/7f06b150-ad39-c008-615c59d6-25a08e69.dmp Operating system: Android 0.0.0 Linux 3.4.0-gadb2201 #1 SMP PREEMPT Wed Nov 20 14:42:53 PST 2013 armv7l CPU: arm ARMv7 Qualcomm Krait features: swp,half,thumb,fastmult,vfpv2,edsp,neon,vfpv3,tls,vfpv4,idiva,idivt 4 CPUs Crash reason: SIGSEGV Crash address: 0x0 Process uptime: not available Thread 12 (crashed) 0 libxul.so!RefPtr<mozilla::DataChannelConnection>::operator-> + 0x1e r0 = 0x804c695d r1 = 0x74e78da7 r2 = 0x74e78da7 r3 = 0x8106eb60 r4 = 0x00000000 r5 = 0x759454a8 r6 = 0x75945500 r7 = 0x75945518 r8 = 0x7594550c r9 = 0x00000000 r10 = 0x76516000 r12 = 0x7f8913d5 fp = 0x75945760 sp = 0x75945488 lr = 0x7e841ff7 pc = 0x7e841ff6 Found by: given as instruction pointer in context 1 libxul.so!mozilla::DataChannel::GetReadyState [DataChannel.h:bad612fd3ab0 : 403 + 0x3] r4 = 0x881bd3c0 r5 = 0x759454a8 r6 = 0x75945500 r7 = 0x75945518 r8 = 0x7594550c r9 = 0x00000000 r10 = 0x76516000 fp = 0x75945760 sp = 0x75945490 pc = 0x7e84269b Found by: call frame info 2 libxul.so!nsDOMDataChannel::UpdateMustKeepAlive [nsDOMDataChannel.cpp:bad612fd3ab0 : 519 + 0x3] r4 = 0x894e7d30 r5 = 0x894e7d64 r6 = 0x75945500 r7 = 0x75945518 r8 = 0x7594550c r9 = 0x00000000 r10 = 0x76516000 fp = 0x75945760 sp = 0x759454b8 pc = 0x7e84cbe9 Found by: call frame info 3 libxul.so!nsDOMDataChannel::Close [nsDOMDataChannel.cpp:bad612fd3ab0 : 255 + 0x5] r4 = 0x894e7d30 r5 = 0x76516000 r6 = 0x75945500 r7 = 0x75945518 r8 = 0x7594550c r9 = 0x00000000 r10 = 0x76516000 fp = 0x75945760 sp = 0x759454d0 pc = 0x7e84cd35 Found by: call frame info 4 libxul.so!mozilla::dom::DataChannelBinding::close [DataChannelBinding.cpp:bad612fd3ab0 : 458 + 0x3] r4 = 0x7594550c r5 = 0x76516000 r6 = 0x75945500 r7 = 0x75945518 r8 = 0x7594550c r9 = 0x00000000 r10 = 0x76516000 fp = 0x75945760 sp = 0x759454d8 pc = 0x7ec47ebd Found by: call frame info 5 libxul.so!mozilla::dom::GenericBindingMethod [BindingUtils.cpp:bad612fd3ab0 : 2812 + 0x3] r4 = 0x7ec47eb1 r5 = 0x80ea935c r6 = 0x75945500 r7 = 0x75945518 r8 = 0x7594550c r9 = 0x00000000 r10 = 0x76516000 fp = 0x75945760 sp = 0x759454f0 pc = 0x7ed0d7cb

:dminor you've been looking at some of these, any idea?

Bug 1300634 happened around the same time with the same backtrace. It doesn't appear to have occurred since and I was unable to find anything on crashstats with the same proto signature.

I'm wondering if bug 1280041 might have closed this already.

Looks like it is crashing here: http://searchfox.org/mozilla-central/rev/008fdd93290c83325de6629a1ae48dc2afaed868/netwerk/sctp/datachannel/DataChannel.h#408 But the strange thing is that the access is actually guarded by an if condition checking exactly that.

Attachment #8809157 [details] is some bandage to avoid the crash (without analyzing why/how we get into this situation). Randell what do you think?

Comment on attachment 8809157 [details] Bug 1297384: avoid mutex access for closed state. https://reviewboard.mozilla.org/r/91790/#review92004 ::: netwerk/sctp/datachannel/DataChannel.h:407 (Diff revision 1) > void SetBufferedAmountLowThreshold(uint32_t aThreshold); > > // Find out state > uint16_t GetReadyState() > { > - if (mConnection) { > + if ((mState != CLOSED || mState != CLOSING) && mConnection) { mState is accessed under lock (the point of touching mConnection here), so we can't do this. See bug 1280041 for other ideas.

Mass change P2->P3 to align with new Mozilla triage process.

Bulk priority update of open intermittent test failure bugs. P3 => P5 https://bugzilla.mozilla.org/show_bug.cgi?id=1381960