Closed Bug 1154051 Opened 5 years ago Closed 5 years ago

Crash in MediaStreamGraph (ringtone) while stability testing

Categories

(Firefox OS Graveyard :: Stability, defect, critical)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:2.2+)

RESOLVED WORKSFORME
blocking-b2g 2.2+

People

(Reporter: ggrisco, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [b2g-crash][caf-crash 613][caf priority: p3][CR 821342])

Crash Data

Attachments

(4 files)

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?
blocking-b2g: 2.2? → 2.2+
Whiteboard: [CR 821342]
Whiteboard: [CR 821342] → [caf priority: p1][CR 821342]
Whiteboard: [caf priority: p1][CR 821342] → [b2g-crash][caf-crash 613][caf priority: p1][CR 821342]
Keywords: crash
Hi! Shawn,

Could someone of your team help on this case?

--
Keven
Flags: needinfo?(sku)
See Also: → 1154042
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.
Flags: needinfo?(sku) → needinfo?(slee)
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.
Flags: needinfo?(slee)
Whiteboard: [b2g-crash][caf-crash 613][caf priority: p1][CR 821342] → [b2g-crash][caf-crash 613][caf priority: p3][CR 821342]
Closing this since we haven't seen it reproduce since AU 126.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.