Closed Bug 583779 Opened 14 years ago Closed 14 years ago

8/2 Android Nightly Build does not open on start-up

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
blocker

Tracking

(fennec2.0a1+)

VERIFIED FIXED
Tracking Status
fennec 2.0a1+ ---

People

(Reporter: aakashd, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

Build id:
Mozilla/5.0 (Android; U; Linux armv71; en-US; rv:2.0b2pre) Gecko/20100802 Namoroka/4.0b3pre Fennec/2.0a1pre


Steps to Reproduce:
1. Download and install the build located at
2. Start up Fennec

Actual Results:
Fennec will not start-up. mbrubeck has mentioned the same behavior in irc:

mbrubeck: The latest Android nightly is crashing on startup on my N1
[07:41am] mbrubeck: with signal 7 (SIGBUS) about half a second after the main window appears
Some more notes from Vlad Maniac:

I am trying now to run smoketests on today's [android] build. 
I can't manage to open Fennec. 

Behavior: 
It opens for a few moments and tries to load Fennec start system page. 
After half progress on that, it crashes and the Android doesn't seem to 
recognize it as a process in the Killer App. 

Tried: 
I have tried so far restarting fennec several times. 
Restarting device. 
Reinstall build.
making sure this gets properly flagged, even though its obvious this will block.
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0a1+
I've bisected this to the last TM merge (http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=3494aba88219) within that merge the problem seems to have started between changesets 144b2bbb24ed and 6d7b95761119, but unfortunately within that range configure fails for android.
Get stack and we'll find out what's up.
Sorry, the stack I'm getting is garbage. We get a SIGBUS and crash. Mwu reports that he doesn't get this on the emulator which is ARMv5, so it may be an ARMv6 or ARMv7 problem.
I think I have a stack: http://pastebin.mozilla.org/761091

At the bottom is says corrupted but the first few frames look valid to me. And it is a misalignment so SIGBUS would be appropriate.

The offending JS file is /services/sync/modules/engines.js at I assume line 140 or 141.

I compiled with --disable-ipc though so things might be different.
I've got the same stack as Jim, with SIGBUS in js_short_strncpy: http://pastebin.mozilla.org/761123
Attached patch PatchSplinter Review
This patch fixes the issue. The crash was a misaligned copy.
Alan, is this patch ready for review?
Yeah, sorry, vlad gave this r+ on IRC in #jsapi. It's ready to be pushed. I don't have commit access, so someone else needs to push it.
Why not just fix the case where we do the unaligned copy, i.e. do 2 word writes and ors with the existing content. For a half-word-by-half-word copying as you do it the compiler has to do a lot of painful bit twiddling. Even in hardware its expensive.
(not opposed to pushing with vlad's r+, but I think the fix here is cheesy)
apierce will file a follow-up to make this less cheesy.
http://hg.mozilla.org/mozilla-central/rev/f74c17026fd2
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Why not use memmove or memcpy?  They should be pretty well optimized.
er, never mind; didn't look at the context
memcpy is horrible unoptimized on macosx. It calls across a shared library boundary and is otherwise also total ****.
verified FIXED on build:

Mozilla/5.0 (Android; U; Linux armv71; en-US; rv:2.0b2pre) Gecko/20100804 Namoroka/4.0b3pre Fennec/2.0a1pre
Status: RESOLVED → VERIFIED
BUG NOT FIXED on ARMv6 build!
On my LG Optimus One P500 which mount an ARMv6 CPU still shows the same issue described below in this bugtrack.
First select the Fennec icon on menu then appears the splash screen with text "loading" and few seconds after return to menu..
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: