Closed Bug 1154042 Opened 5 years ago Closed 5 years ago

Crash in ringtone app 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 612][caf priority: p3][CR 821339])

Crash Data

Attachments

(4 files)

Saw this crash signature while stability testing:

[@ ? | nsRuleNode::DestroyInternal | nsRuleNode::DestroyInternal | nsStyleSet::Shutdown ]

Logs are showing ringtone as the current app and there are several references to ringtone in the logs.

Could be related to bug 1152439.
blocking-b2g: 2.2? → 2.2+
Whiteboard: [CR 821339]
Whiteboard: [CR 821339] → [caf priority: p1][CR 821339]
Whiteboard: [caf priority: p1][CR 821339] → [b2g-crash][caf-crash 612][caf priority: p1][CR 821339]
Keywords: crash
Hi! Shawn,

Looks like the same case as bug 1154051?

--
Keven
Flags: needinfo?(sku)
See Also: → 1154051
Hi David,
 May we have your comment to see why SIGSEGV was hit for this case?

Hi Rex,
 Please also check this in parallel.
Flags: needinfo?(sku)
Flags: needinfo?(rhung)
Flags: needinfo?(dbaron)
(In reply to Keven Kuo [:kkuo] from comment #6)
> Hi! Shawn,
> 
> Looks like the same case as bug 1154051?
> 
> --
> Keven

I don't think 1154051 and this one share the same root cause after checking the minidump info.
Already ni dbaron to see if any idea from layer's viewpoint.
Let's see.

attachment 8591900 [details] (comment 2) and attachment 8592020 [details] (comment 5) are identical files.  (Not sure if that was intentional.)  attachment 8591899 [details] (comment 1) and attachment 8592019 [details] (comment 4) are also the same file.

Assuming that comment 3 is accurate commit info for both, then:
 $ git show 6bb2afcce9872a7cbc65b4a58f752e2d5ac02345:layout/style/nsRuleNode.cpp
shows that the crash is at (or maybe immediately before) the  "this->~nsRuleNode()" in DestroyInternal.

That assumes, however, that frame #1 is valid, rather than just garbage on the stack.  It does make sense, though, since frame #2 would call frame #1.

Since there's no good line number from nsStyleSet::Shutdown (since it's picking the line number it inlined), it's not clear whether this is mRuleTree->Destroy() or mOldRuleTrees[i]->Destroy.

Either way, I don't have much of an idea of what would cause this.  Some sort of memory corruption is certainly a possibility, and it seems more likely than not that whatever went wrong happened well before the crash stack.
Flags: needinfo?(dbaron)
Whiteboard: [b2g-crash][caf-crash 612][caf priority: p1][CR 821339] → [b2g-crash][caf-crash 612][caf priority: p3][CR 821339]
Hi, Greg,

Could you let us know what kind of stability test you ran in this bug? Is it possible for us to run the same test locally?
Flags: needinfo?(rhung) → needinfo?(ggrisco)
(In reply to Rex Hung[:rhung] from comment #10)
> Hi, Greg,
> 
> Could you let us know what kind of stability test you ran in this bug? Is it
> possible for us to run the same test locally?

Hi Rex,

In stability, we are running monkey type tests where the steps are indeterminate.  We run these tests overnight and on weekend.  You won't be able to exactly replicate the steps but with clever monkey you can probably catch similar set of crashes (or find new ones).

These ringtone crashes have not reproduced in AU 129 or AU 132 which is strange since they were so prevelant in AU 126.  This makes me wonder if bug 1154411 is related or in some way is preventing these crashes from happening.
Flags: needinfo?(ggrisco)
> These ringtone crashes have not reproduced in AU 129 or AU 132 which is
> strange since they were so prevelant in AU 126.  This makes me wonder if bug
> 1154411 is related or in some way is preventing these crashes from happening.

Actually, I cannot see AU 126(AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.126) manifest XML file in msm8909 manifest git. Is it really available for us? Besides, before you start the stability test, is there any extra patches which are applied to your local build? Could you share with us the related information?
Flags: needinfo?(ggrisco)
I think it doesn't make sense to attempt to reproduce this now since we haven't been able to reproduce it over past several builds.  I'm going to close this one for now.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(ggrisco)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.