Saw this crash signature while stability testing: [@ DeviceStorageUsedSpaceCache::CacheEntry::AddRef | mozilla::MediaSegmentBase::AppendSliceInternal | mozilla::AudioNodeExternalInputStream::ProcessInput | mozilla::MediaStreamGraphImpl::ProduceDataForStreamsBlockByBlock ] Could be related to bug 1152439.

looks like bug 1154030 is similar case?

Observed on: Device: msm8909 Gonk Version: AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.126 Moz BuildID: 20150406002503 Manifest: https://www.codeaurora.org/cgit/quic/lf/b2g/manifest/tree/caf_AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.126.xml?h=release Gecko Version: 37.0 Gaia: http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=a6351e1197d54f8624523c2db9ba1418f2aa046f Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=6bb2afcce9872a7cbc65b4a58f752e2d5ac02345 Patches: bug 1148641, bug 1150923, bug 1152095, bug 1150924, bug 1133147, bug 1150271, bug 1150916, bug 1152361

Hi! Shawn, Could someone of your team help on this case? -- Keven

Hi Steven, it looks like this was the similar symptom that use the memory after free it. But, it should not the same issue as Bug 1154042.

According to the crash address(0x5a5a5a5e), it seems be a use-after-free memory access and some class instance kept by smart pointer has been released before its reference counter is increased. However, last two frames in minidump result is weird to me. I cannot make a connection between them after code review. Will keep checking the bug and update my finding if any. ========================== Crash reason: SIGBUS Crash address: 0x5a5a5a5e Thread 22 (crashed) 0 libxul.so!DeviceStorageUsedSpaceCache::CacheEntry::AddRef [Atomics.h : 445 + 0x4] r0 = 0x5a5a5a5e r1 = 0x00000020 r2 = 0x5a5a5a5a r3 = 0x5a5a5a5a r4 = 0xb1fb5f28 r5 = 0xb1f69428 r6 = 0xaf5246b8 r7 = 0x00000001 r8 = 0xb1f28684 r9 = 0x00000001 r10 = 0x0000025c r12 = 0xb65ce750 fp = 0x00000000 sp = 0xaf5245c0 lr = 0xb538e801 pc = 0xb4b1a868 Found by: given as instruction pointer in context 1 libxul.so!mozilla::MediaSegmentBase<mozilla::AudioSegment, mozilla::AudioChunk>::AppendSliceInternal [nsISupportsImpl.h : 356 + 0x5] r4 = 0xb1fb5f28 r5 = 0xb1f69428 r6 = 0xaf5246b8 r7 = 0x00000001 r8 = 0xb1f28684 r9 = 0x00000001 r10 = 0x0000025c fp = 0x00000000 sp = 0xaf5245c0 pc = 0xb538e801 Found by: call frame info

(In reply to shawn ku [:sku] from comment #8) > Hi Steven, > it looks like this was the similar symptom that use the memory after free > it. yes. > But, it should not the same issue as Bug 1154042. agree, we are trying to figure out where the problem is. (In reply to Rex Hung[:rhung] from comment #9) > According to the crash address(0x5a5a5a5e), it seems be a use-after-free > memory access and some class instance kept by smart pointer has been > released before its reference counter is increased. > However, last two frames in minidump result is weird to me. I cannot make a > connection between them after code review. Will keep checking the bug and > update my finding if any. I think that's because the compiler optimises the source code and compiles some similar templates as the same one.

Closing this since we haven't seen it reproduce since AU 126.