Closed Bug 1001293 Opened 10 years ago Closed 7 years ago

[MTBF] Crash after a day of not running anything

Categories

(Firefox OS Graveyard :: MTBF, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: wachen, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

Attached file tmp.zip (obsolete) (deleted) —
hamachi v1.4 pvt build 20140421160203 Gaia 26432916d10434103a822f17be4624a342cadfba Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/211431128e5b BuildID 20140421160203 Version 30.0a2 ro.build.version.incremental=324 ro.build.date=Thu Dec 19 14:04:55 CST 2013 This crashed after hours of just putting the phone in the lab. attached minidump
Hopefully there will be someone looking at this bug.
Blocks: 988176
No longer blocks: 988176
Blocks: MTBF-meta
Summary: [MTBF] Crash Report after a day of no running anything → [MTBF] Crash after a day of no running anything
Blocks: 1001300
No longer blocks: MTBF-meta
Does this build have symbols? The stack in the attached zip seems to imply that the build doesn't have symbols. Thread 0 (crashed) 0 libc.so + 0xd604 r4 = 0x00000000 r5 = 0xbec21638 r6 = 0x00000001 r7 = 0x000000fc r8 = 0x00000014 r9 = 0x00000000 r10 = 0x00000001 fp = 0x00000000 sp = 0xbec21600 lr = 0x400bb121 pc = 0x40059604 Found by: given as instruction pointer in context 1 libxul.so + 0x8a8d4d sp = 0xbec21610 pc = 0x412dcd4f Found by: stack scanning 2 libxul.so + 0x8a0287 sp = 0xbec21638 pc = 0x412d4289 Found by: stack scanning
Attached file Minidump (deleted) —
Jason, thanks, I created a nicely passed minidump.
Attachment #8412385 - Attachment is obsolete: true
Attachment #8412416 - Attachment is obsolete: true
*PS. the link in comment 6 is symbols, the files in zip is minidump
Hi, Eric, please help with this bug.
Flags: needinfo?(echou)
Summary: [MTBF] Crash after a day of no running anything → [MTBF] Crash after a day of not running anything
Just checked the log. It looks like the system crashed in Atomics.h while an Atomic<bool> was used and was swapped. Unfortunately frame 2 is broken so we can't know more about the stack, but it might be related to mozilla::Atomic<bool> mNativeEventPending; which is defined in widget/xpwidgets/nsBaseAppShell.h according to the log. I think it would be better to let an expert to do further investigation. ni vikstrous, the author of [Atomic<bool>], to see if he have any idea of how this occurred.
Flags: needinfo?(echou) → needinfo?(vikstrous)
I'm not an expert. I looked at this briefly and I'm just as confused as you, but maybe Nathan Froyd can help. I implemented Atomic<Bool> with his help.
Flags: needinfo?(vikstrous) → needinfo?(nfroyd)
(In reply to Viktor Stanchev [:vikstrous] from comment #10) > I'm not an expert. I looked at this briefly and I'm just as confused as you, > but maybe Nathan Froyd can help. I implemented Atomic<Bool> with his help. I can look, but I'm have no idea how to deal with raw minidumps. Walter, can you provide the symbolicated stack from the minidump and a link to the associated libxul?
Flags: needinfo?(nfroyd) → needinfo?(wachen)
result3.txt is parsed minidump
Flags: needinfo?(wachen)
(In reply to Walter Chen[:ypwalter][:wachen] from comment #12) > result3.txt is parsed minidump Where is result3.txt? The only attachment I see is "Minidump" and there's no reference to result3.txt in any of the prior comments. Did you forget to attach something?
Flags: needinfo?(wachen)
(In reply to Nathan Froyd (:froydnj) from comment #13) > (In reply to Walter Chen[:ypwalter][:wachen] from comment #12) > > result3.txt is parsed minidump > > Where is result3.txt? The only attachment I see is "Minidump" and there's > no reference to result3.txt in any of the prior comments. Did you forget to > attach something? The attachment "Minidump" is actually a zip file and it contains result3.txt, which is the parsed minidump. :)
(In reply to Eric Chou [:ericchou] [:echou] from comment #14) > (In reply to Nathan Froyd (:froydnj) from comment #13) > > (In reply to Walter Chen[:ypwalter][:wachen] from comment #12) > > > result3.txt is parsed minidump > > > > Where is result3.txt? The only attachment I see is "Minidump" and there's > > no reference to result3.txt in any of the prior comments. Did you forget to > > attach something? > > The attachment "Minidump" is actually a zip file and it contains > result3.txt, which is the parsed minidump. :) Ah, very good! I did not look far enough. My mistake. I guess then: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-hamachi-eng/2014/04/2014-04-21-16-02-03/b2g-30.0a2.en-US.android-arm.tar.gz contains the appropriate libxul that was present when this crashed?
Minidump (62.64 KB, application/zip) -> application/zip -> zip file and the file u indicated is correct
Flags: needinfo?(wachen)
close per no response since a year ago.
Status: NEW → UNCONFIRMED
Component: General → MTBF
Ever confirmed: false
Firefox OS is not being worked on
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: