Closed Bug 694566 Opened 13 years ago Closed 12 years ago

[birch] crashes on install @ mozalloc_abort | __swrite | nsBufferedStream::Init

Categories

(Firefox for Android Graveyard :: General, defect, P2)

ARM
Android
defect

Tracking

(fennec11+)

RESOLVED WORKSFORME
Tracking Status
fennec 11+ ---

People

(Reporter: kbrosnan, Assigned: gcp)

Details

(Keywords: crash, crashreportid, Whiteboard: str-wanted, [native-crash])

Crash Data

When I install or update birch builds (native UI) from the ftp I get a crash. From then on I am able to use the build.

HTC G2
Android 2.2
75f1ff86-9236-4304-90da-c9a752111012
68af22cb-ef61-4530-bdca-946522111013
0ece1af1-5d06-4eeb-a01c-eb09c2111014
HTC Evo
Android Version 2.3.3

I downloaded a birch build on Friday and I was getting this same crash pretty consistently on my phone. The crashes were happening after I already installed.
Product: Fennec → Fennec Native
Version: Trunk → unspecified
I am continuing to get this crash regularly with builds ever day.  happens at random times.
Are we not uploading symbols for birch builds to the symbol server? We don't have libxul symbols for the crashes in comment 1, which will make this kind of hard to debug!
str needed.
In my case with the HTC Evo, I am wondering if it has something to do with HTC Sense interfering. Unfortunately I don't have a distinct set of STR for this bug, but all of the crashes on my phone since I started running the birch builds are in this stack.

A minute ago I put my phone down with a crash page loaded, and the browser crashed. Here is that report:

https://crash-stats.mozilla.com/report/index/bp-cb17e9ac-7843-4711-9489-441452111027 is that crash.
1. install nightly (10/25/2011)
2. run the build
3. set in the background
4. download nightly (10/27/2011)
5. switch back to the nightly after the download is done.

Expected: no crash
Actual: crash.

Note:  Marcia is getting.  I am uncertain if it's the same [@ mozalloc_abort | __swrite ] as Kevin is seeing.

App Notes 	java.lang.RuntimeException: Unable to start activity ComponentInfo{org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1821)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1842)
at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:3288)
at android.app.ActivityThread.access$1600(ActivityThread.java:132)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1042)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:143)
at org.mozilla.gecko.GeckoApp$19.run(GeckoApp.java:1064)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4263)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invo
(oops.  meant download nightly with the default browser in step 4)
An NPE crash fix landed in bug 697528 an hour or two ago [1]. Can you try out the associated Android build? [2]

[1] https://tbpl.mozilla.org/?tree=Birch&rev=e87286aa52e0
[2] http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/birch-android/1319727850/
I can't seem to crash on this build with the same STRs that I placed in.  I'll ask Marcia to try it on her phone to see if it's stable for her.
Using the build in Comment 9 I have not been able to crash yet on HTC Evo. Will report back if something changes.
Assignee: nobody → doug.turner
Priority: -- → P2
Whiteboard: str-wanted → str-wanted, [native]-crash
Whiteboard: str-wanted, [native]-crash → str-wanted, [native-crash]
Crash Signature: [@ mozalloc_abort | __swrite ] → [@ mozalloc_abort | __swrite ] [@ mozalloc_abort | __swrite | nsBufferedStream::Init ]
no working str.
Assignee: doug.turner → nobody
I see the same behaviour on my HTC Desire. Clearing the app's data allows me to proceed with using nightly.
Assignee: nobody → gpascutto
Setting to [native-crash:P2] since Eng has set it as a P2, nhirata to try to find repro steps.
Whiteboard: str-wanted, [native-crash] → str-wanted, [native-crash:P2]
Keywords: topcrash
Whiteboard: str-wanted, [native-crash:P2] → str-wanted, [native-crash]
Keywords: topcrash
Summary: [birch] crashes on install [@ mozalloc_abort | __swrite ] → [birch] crashes on install @ mozalloc_abort | __swrite | nsBufferedStream::Init
Scoobidiver, please don't touch the topcrash keywords, the CrashKill team is trying to use it thoughtfully and get people to work on bugs that have it, and without any comment as to why it is added or removed, it should never be touched at all. Also, criteria on where to use it in Fennec might not even be fully clear yet.
Keywords: topcrash
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #16)
FWIW, I think the topcrash keyword should be added for:
* the top 50 in 8 and 9 (Fx or TB)
* the top 10 in Aurora and trunk (Fx or TB)
* the top 5 in 8 and 9 on Mac OS X or Linux (Fx or TB)
* the top 10 in Fennec 8 and trunk
(In reply to Scoobidiver from comment #17)
> (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #16)
> FWIW, I think the topcrash keyword should be added for:

Our criteria are probably not far apart but as we are working to commit Mozilla-paid workforce on topcrash bugs, we need to control what can be counted there. FWIW, Thunderbird is its own topic and out of scope right now, it probably also has different priorities. Fennec also has different priorities given to low user numbers and the complete UI rewrite going on, and we need to clear up with Naoki, who is our "mobile person" in CrashKill, where we set those.

Please _never_ change that keyword without a comment of _why_ you are adding or removing it, that is the first, most helpful step. This way, both us and the developers know what is going on.

Another helpful step would be to dial into our weekly CrashKill meetings where we coordinate our efforts and/or coordinate in the #crashkill channel on IRC. We value your help a lot but we need to ensure we are all pulling in the same direction there.
It was a top crasher when there was only the mozalloc_abort | __swrite crash signature which matches bug 692961, bug 693484, bug 697528, bug 698633, bug 702244, bug 702248, bug 703415, bug 704467, bug 704511 and this bug.
Now that __swrite has been added to the Socorro skiplist, we can determine the amount of crashes of each sub signature.
There have been only 10 crashes for the last four weeks, all in 10.0a1 from 3 different users.
It's no longer a top crasher.
Keywords: topcrash
Noaki, do you agree with that assessment? I have no clue about those __swrite crashes.
yes.  Scoobidiver is spot on.
tracking-fennec: --- → 11+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.