886736 - Nightly 24.0a on Sony Xperia Z running CyanogenMod 10.x freezes for 20-30 second or reboots at every start (ANR)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Marcin Norest]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130623031022

Steps to reproduce:

I running Nightly.


Actual results:

When I running Firefox Nightly 24.0a my phone (Sony Xperia Z) freezes for 20-30 second or reboots. This happens every time when I start the FF.
Beta, Aurora works perfectly.


Expected results:

Should be works.

Comment 1

[Aaron Train [:aaronmt]]

Please attach to this bug a logcat from your Android device when you encounter this issue.

Comment 2

[Marcin Norest]

I don't know how get log from Nightly for android. I install new version v25.0a and it's the same, and phone is very hot :/ (I kill this app)

Comment 3

[Aaron Train [:aaronmt]]

You can use https://play.google.com/store/apps/details?id=org.jtb.alogcat to capture and attach to this bug a log saved from the device. Run Firefox, after a freeze switch back to aLogCat, save the log and attach it here to this bug.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

I am unable to reproduce using an Xperia Z running Android 4.1.2 and Firefox Beta or Nightly (v25).

Comment 5

[Marcin Norest]

Not possible :/ My phone rebooting every time.
Now first Aurora 24.0a2 not works :/

Comment 6

[Marcin Norest]

Only if I'm only on firefox is possible to use phone after "firefox freeze bug" (with aLogcat, phone automatically restarts), but sound in phone not works after this event, I must reboot phone.

OS: Android 4.2.2

Comment 7

[Aaron Train [:aaronmt]]

It sounds like there's something in your environment which is causing issues on your phone since we are unable to reproduce on our Xperia Z. In order to make this bug actionable we need logs from your phone which may or may not showcase your issue.

Comment 8

[Marcin Norest]

I have log, created by CatLog app from play store: http://pastebin.com/gCEhhf7V
Log is with filter "fennec" to save only about ff.

Comment 9

[Aaron Train [:aaronmt]]

You'll need to capture more, there's nothing of value in that first attempt.

Comment 10

[Marcin Norest]

Ok, maybe this is better: http://pastebin.com/Q4Xrzk3Z

I set in settings:
Log Buffer(s) -> Main, Events, Radio (all options)
Default Log Level -> What a Terriible Failure (other for select: Verbose, Debug, Info, Warn, Error)
And filter for save logs: fennec

Comment 11

[Aaron Train [:aaronmt]]

Thanks, yes.

It appears that you are hitting an ANR (Application Not Responding) situation on your device. When this happens Android will write stacks to /data/anr/traces.txt

Can you pull from the device traces.txt and attach it to this bug? You will need the Android SDK:

$ adb pull /data/anr/traces.txt

06-27 21:01:15.773 E/ActivityManager(719): ANR in org.mozilla.fennec (org.mozilla.fennec/.App)
06-27 21:01:15.773 E/ActivityManager(719):   7.3% 7665/org.mozilla.fennec: 0% user + 7.2% kernel / faults: 15806 minor 108 major
06-27 21:01:15.773 E/ActivityManager(719):   96% 7665/org.mozilla.fennec: 0% user + 96% kernel / faults: 44 minor

Comment 12

[Marcin Norest]

Error Level: http://pastebin.com/ReiLcPVM
Debug Level: http://pastebin.com/bqf9iXeB

traces.txt: http://pastebin.com/hEew8YEc

Comment 13

[Aaron Train [:aaronmt]]

Attachment: traces.txt

Comment 14

[Kevin Brosnan [Ex-Mozilla]]

Jim can you take a look at traces.txt and see if there is useful info?

Comment 15

[Marcin Norest]

My reports will help fix the problem?

Comment 16

[Kevin Brosnan [Ex-Mozilla]]

I don't know. I asked one of the developers that can better understand the information in traces.txt to have a look at the file.

Comment 17

[(inactive) Jim Chen [:jchen] [:darchons]]

Sorry for the late response. The ANR report definitely shows some kind of bug, but I'm not sure what bug.


Marcin, it will help us very much if you can determine the date that this problem first appeared. The way to do that is to download Nightly from different dates, and see if the problem appears using each date's Nightly. The fastest way to narrow down the range is to test the middle of the previous range.

For example, if Nightly from Jan 1 works, but Nightly from Jul 1 does not, you can try the Nightly from Apr 1 next. If Nightly from Apr 1 works, you can try May 15 next; if Nightly from Apr 1 does not work, you can try Feb 15 next. This way you can quickly narrow down the range. Let me know if you have questions!

You can download all the Nightly from here, http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/

Comment 18

[(inactive) Jim Chen [:jchen] [:darchons]]

Also, Nightlies are inside the 'mozilla-central-android' directories.

Comment 19

[Marcin Norest]

Ok, no problem :)
All builds from June not works. I will test from May...
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013/05/

I downloaded builds from "%DATE%-%TIME%-mozilla-central-android" directory.
YYYY-MM-DD
2013-05-14 - works ok
2013-05-20 - works ok

2013-05-21 - not works
2013-05-22 - not works
2013-05-23 - not works
2013-05-24 - not works
2013-05-25 - not works, and probably all after this day

Comment 20

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to Marcin Norest from comment #19)
> Ok, no problem :)
> All builds from June not works. I will test from May...
> http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013/05/
> 
> I downloaded builds from "%DATE%-%TIME%-mozilla-central-android" directory.
> YYYY-MM-DD
> 2013-05-14 - works ok
> 2013-05-20 - works ok
> 
> 2013-05-21 - not works
> 2013-05-22 - not works
> 2013-05-23 - not works
> 2013-05-24 - not works
> 2013-05-25 - not works, and probably all after this day

Great! Thank you! :)

Now can you try this special Nightly? I think it will not have this problem.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a4857b6b9397/try-android/fennec-25.0a1.en-US.android-arm.apk

Comment 21

[Marcin Norest]

Yes, this build is without this bug.
No freezes and works fast.
Thanks for fix :)

Comment 22

[Kevin Brosnan [Ex-Mozilla]]

Well that points to bug 874708. Glandium have any thoughts?

Comment 23

[Mike Hommey [:glandium]]

That would be bug 848764. Interestingly, the logs suggest it's going as far as running gecko code, so it's something different from the issue we had with bug 875824, although we can apply the same kind of workaround.

That being said, one thing that bothers me is that aurora should be affected, and according to the original report, it isn't...

Comment 24

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to Mike Hommey [:glandium] from comment #23)
> That would be bug 848764. Interestingly, the logs suggest it's going as far
> as running gecko code, so it's something different from the issue we had
> with bug 875824, although we can apply the same kind of workaround.
> 
> That being said, one thing that bothers me is that aurora should be
> affected, and according to the original report, it isn't...

The report is from before the merge. Both 24 and 25 are affected.

Comment 25

[Mike Hommey [:glandium]]

Ah, that makes sense. Has anyone other than the reporter been able to reproduce on the same device?

Comment 26

[Kevin Brosnan [Ex-Mozilla]]

Unable to reproduce on our Xperia Z. But our Sony Xperia Z (model c6603) is on Android 4.1.2. 

I am unsure what version of Android the reporter is using. 

There is an Android 4.2.2. update that is in the process of staged roll outs. It seems our phone is not in the groups that are currently updating. I forced the check in the system settings. We may be able to flash the device assuming we can find trustworthy images.

Comment 27

[Mike Hommey [:glandium]]

Comment 6 says 4.2.2.

Comment 28

[Mike Hommey [:glandium]]

Marcin, could you get new logs from this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-85b8c1f0e883/try-android/fennec-25.0a1.en-US.android-arm.apk ? Thanks.

Comment 29

[Marcin Norest]

New logs:
debug level - http://pastebin.com/nqwZPvh2
error - http://pastebin.com/zy22sAkV


Android version: 4.2.2 (http://i.imgur.com/KaORLZk.png)

Comment 30

[Kevin Brosnan [Ex-Mozilla]]

Attachment: error log from pasbin

Comment 31

[Kevin Brosnan [Ex-Mozilla]]

Attachment: debug log from pastibin

Comment 32

[Mike Hommey [:glandium]]

These logs seem incomplete. Specifically, there should be things like this:
E/GeckoLinker(28757): Caught segmentation fault @0x58dc6b94
E/GeckoLinker(28757): Within the address space of a CustomElf
E/GeckoLinker(28757): ensure @0x58dc6b94
E/GeckoLinker(28757): DecompressChunk #343 @0x55c78000 (16384/ 16384)
E/GeckoLinker(28757): cacheflush(0x55c78000, 0x55c7c000)
E/GeckoLinker(28757): mprotect @0x58dc6000, 0x4000, 0x5

And others like this:
E/GeckoLinker(28757): /data/app/org.mozilla.fennec-2.apk!/assets/libnss3.so: firstLoadURI; 46/124 chunks decompressed
E/GeckoLinker(28757): [****************____________________________________************]
E/GeckoLinker(28757): [*********_*____*_**__*****__________________________________]

That is, the equivalent of the first line (firstLoadURI; 46/124 chunks decompressed) can be seen in your logs, but not the subsequent lines. There's nothing in the fennec code that would explain this.

Anyways, the log shows that you're successfully going up to firstLoadURI in native code. I really don't see what could be wrong here with on-demand decompression, since going up to firstLoadURI requires a lot of it.

Comment 33

[Aaron Train [:aaronmt]]

What are the next steps here?

Comment 34

[Mike Hommey [:glandium]]

(In reply to Aaron Train [:aaronmt] from comment #33)
> What are the next steps here?

At this point, it would be good that someone gets a hand on a 4.2.2 Xperia Z and reproduces.

Comment 35

[Mike Hommey [:glandium]]

Marcin, could you check a current nightly? There were recent changes to the linker that may have improved things (crossing fingers).

Comment 36

[Marcin Norest]

phone reboot after start, still not works

nightly from 01.08

Comment 37

[Marcin Norest]

I created new logs with traces file.
nightly from 04.08.2013

https://www.dropbox.com/s/qq1f6umzkawv69q/nightly_20130804_logs.zip

Comment 38

[Kevin Brosnan [Ex-Mozilla]]

Glandium anything useful here?

Comment 39

[Marcin Norest]

firefox 24 beta 1 not works...

Comment 40

[Mike Hommey [:glandium]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #38)
> Glandium anything useful here?

Unfortunately not :(
What do you think about disabling on-demand decompression on xperias with android >= 4.2?

Comment 41

[Mark Finkle (:mfinkle) (use needinfo?)]

The plan is to wait and see how many people are affected on Beta before making a decision. Fx24 goes to Beta by next week.

Comment 42

[Marcin Norest]

still nothing?

Comment 43

[bhavana bajaj [:bajaj]]

(In reply to Mark Finkle (:mfinkle) from comment #41)
> The plan is to wait and see how many people are affected on Beta before
> making a decision. Fx24 goes to Beta by next week.

Mark how are we planning on getting this data to make a call for action for Fx24 ?
Is backing out https://bugzilla.mozilla.org/show_bug.cgi?id=848764 not an option at all ?

As a start I am cc'ing :Tyler here to help us check SUMO/Playstore if we have heard any input on this.Tyler is there any way we can get population info of users on this device running 4.2.2 which are the know pool of users affected.

Comment 44

[Mark Finkle (:mfinkle) (use needinfo?)]

The plan is to look for negative feedback from Xperia users. Tyler's group collects that data.

We do not intend to backout bug 848764. Instead, we have a blacklist mechanism that allows us to keep devices from using the decompression code path. If we get data showing this is a common problem for Xperia users, we intend to blacklist those devices.

Comment 45

[(inactive) Jim Chen [:jchen] [:darchons]]

FWIW, I don't see a large number of ANRs for Xperia Z on 24+. It's possible though, that Fennec freezes before ANR reports could be sent (usually during idle time).

Comment 46

[Marcin Norest]

Problem is on CyanogenMod 10.1 or 10.2. On official sony 4.2.2 not.
But problem is with Firefox, build 2013-05-20 works, next build not.
Why?

Comment 47

[:Cykesiopka]

FWIW, on my Xperia Z (C6603), running CM 10.2:

2013-05-19-03-10-35: OK
2013-05-20-03-12-30: OK
2013-05-21-03-11-06: Not OK
2013-05-22-03-10-27: Not OK

2013-08-22-03-02-04: Not OK
24b4: Not OK
... which matches up with the regression range in Comment 19.

Specifically on 2013-08-22-03-02-04:
1. Launch FF
2. FF UI freezes after either of the below:
   - UI loads, can open the menu
   - UI partially loads
3. System UI doesn't respond to input/freezes
4. Any of the below:
   - <= 30 secs later, FF and System UI unfreeze
   - <= 30 secs later, phone gets rebooted
   - Crash + ANR notification, e.g. https://crash-stats.mozilla.com/report/index/7f6a09d0-2143-4703-9ac1-e41ec2130822

I apologise in advance if what I'm experiencing is actually another bug.

Comment 48

[Kevin Brosnan [Ex-Mozilla]]

This only is an issue with CM 10.x we need to figure out if this our issue or a CM issue. Neither Tyler nor Matt will see this in user feedback.

Comment 49

[Mike Hommey [:glandium]]

Attachment: Test program

Marcin, could you download this attachment, push it on your device, in e.g. /data/local/tmp, then run it, and report the output of adb logcat | grep SIGSEGV?

Comment 50

[Mike Hommey [:glandium]]

It looks like this is not a general cyanogenmod problem, as running a nightly on a nexus s running cyanogenmod 10 works.

Comment 51

[Mike Hommey [:glandium]]

Better than testing that attachment, can you test this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-58391ce5fe5b/try-android/fennec-26.0a1.en-US.android-arm.apk ?

Comment 52

[Marcin Norest]

@Mike
Not works.

Test attachment ? https://bugzilla.mozilla.org/show_bug.cgi?id=886736#c49

Comment 53

[Mike Hommey [:glandium]]

(In reply to Marcin Norest from comment #52)
> Test attachment ? https://bugzilla.mozilla.org/show_bug.cgi?id=886736#c49

Yes, please.

Comment 54

[Mike Hommey [:glandium]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #48)
> This only is an issue with CM 10.x we need to figure out if this our issue
> or a CM issue. Neither Tyler nor Matt will see this in user feedback.

Is it possible to install CM 10.x on one of the xperia z mozilla has and try to reproduce with a nightly? If that's reproducible, then remote access like we did for the HTC One X would probably allow to find a reason and possibly a fix/workaround.

Comment 55

[Marcin Norest]

Sorry, but I don't know how to run it.
I connected phone to the my notebook (with win7), next I copy file to directory.
My commands:
adb push C:\foo /data/local/tmp
adb shell
cd /data/local/tmp
and ?

I typed foo, start foo, hmmm...

last step is:
adb logcat | C:\"Program Files (x86)"\GnuWin32\bin\grep SIGSEGV >> C:\logcat_foo.txt
(grep on windows works)

Comment 56

[Kartikaya Gupta (email:[e-mail])]

Marcin: try "./foo" after you cd to /data/local/tmp. You might also need to run "chmod +x foo" before "./foo"

Comment 57

[Marcin Norest]

I set chmod 777 foo. I try ./foo
shell@android:/data/local/tmp $ ./foo
./foo
[1] + Stopped (signal)     ./foo
shell@android:/data/local/tmp $ ./foo
./foo
[2] + Stopped (signal)     ./foo
[1] - Segmentation fault   ./foo

and adb logcat > C:\logcat_foo.txt

OUTPUT:
F/libc    ( 7755): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 7755 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 7831): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 7831 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 7833): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 7833 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8224): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8224 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8304): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8304 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8330): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8330 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 7755): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 7755 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 7831): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 7831 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 7833): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 7833 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8224): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8224 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8304): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8304 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8330): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8330 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b
F/libc    ( 8354): Fatal signal 11 (SIGSEGV) at 0x0000007b (code=1), thread 8354 (foo)
I/DEBUG   (  235): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000007b

Comment 58

[Mike Hommey [:glandium]]

Marcin, thanks for that output. It unfortunately means it's not the same as bug 907957 (as the failure of the try build suggested), so we're back to square one, not knowing what's going on at all :(

To attempt to reproduce on our end, which cyanogenmod ROM are you using exactly?

Comment 59

[Marcin Norest]

CM 10.2 (Android 4.3) 20130828: http://get.cm/?device=yuga

For Firefox works the same as CM10.1 (Android 4.2.2).

Comment 60

[Ryan VanderMeulen [:RyanVM]]

Fixed on beta by backing out bug 848764.

Comment 61

[Marcin Norest]

any build for testing ?

Comment 62

[Mike Hommey [:glandium]]

(In reply to Marcin Norest from comment #61)
> any build for testing ?

http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-beta-android/1378334954/fennec-24.0.en-US.android-arm.apk

Comment 63

[Marcin Norest]

works perfectly on CM10.2 20130904, very fast :)

Comment 64

[Mike Hommey [:glandium]]

So, the problem is that some qcom stuff on code aurora set user_debug=31 on the kernel command line. This ended up in production phones, including the xperia Z stock ROM, but somehow, it's only noticeably worse on CM 10.x. But there's enough overhead from user_debug=31 on the xperia Z stock ROM that we might get faster startups without on-demand decompression.

Considering this stupidity is on code aurora, set by default on several different platforms (I only checked three, and two had it), it's likely to affect a lot of production phones.

Unfortunately, /proc/cmdline is not readable, and it's hard to detect if we're under those conditions or not. I'll try to find a reasonable timing over which we can safely consider on-demand decompression is not going to be doing any good.

Comment 65

[Mike Hommey [:glandium]]

(In reply to Mike Hommey [:glandium] from comment #64)
> So, the problem is that some qcom stuff on code aurora set user_debug=31 on
> the kernel command line.

This makes the kernel log various info about userspace segmentation faults, including a stack trace. That adds some noticeable delay between the instruction that segfaults and the handler being called.

Comment 66

[:Cykesiopka]

Could Bug 848764 be backed out on Beta 25 as well?
(Currently broken for CM10.1.3 Final)

Comment 67

[Kevin Brosnan [Ex-Mozilla]]

Are we going to back this out of beta 25 as well?

Comment 68

[Mike Hommey [:glandium]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #67)
> Are we going to back this out of beta 25 as well?

I guess this is the reasonable thing to do until we have a validated workaround.

Comment 69

[Mike Hommey [:glandium]]

I did a try build to attempt to evaluate the right threshold we'll need to apply to avoid this bug while keeping on-demand decompression for devices where it works well.

Could QA test the builds below on various types of devices, and report what "SEGVHandler latency" they report on logcat?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5393aa5a4df6/

I'm obviously interested in the value this gets for xperia z under cyanogenmod, but also under stock rom, and the more other devices as possible, especially slow ones (like low end armv6 devices).

Comment 70

[Joe Robinson]

I still experience the same freezing/crashing issues with http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5393aa5a4df6/try-android/fennec-27.0a1.en-US.android-arm.apk on my Xperia Z running Cyanogenmod 10.1.3. SEGVHandler latency is reported as 118133545. Let me know if you need any further logs.

Comment 71

[Aaron Train [:aaronmt]]

A couple of oldish devices I have here

* HTC Nexus One (Stock Android 2.3)
** E/GeckoLinker( 1012): SEGVHandler latency: 30517

* Samsung Galaxy SII (Stock Android 4.1)
** E/GeckoLinker( 5381): SEGVHandler latency: 31541

* Samsung Nexus S (Stock Android 4.1)
** E/GeckoLinker( 2222): SEGVHandler latency: 30250

I've requested SoftVision to help out by providing some more values on slower older devices as well.

Comment 72

[:Cykesiopka]

For https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5393aa5a4df6/try-android/fennec-27.0a1.en-US.android-arm.apk :

- Samsung Galaxy S3 <I9300> (Stock 4.1.2 : I9300ZSEMC1): 24959, 29500, 27833, 36375, 32000, 36125
- Nexus 7 2012 <Grouper> (CM 10.2 : 10.2-20131007-NIGHTLY-grouper): 38000, 39000, 36000, 35000, 42000

Comment 73

[Teodora Vermesan (:TeoVermesan)]

(In reply to Mike Hommey [:glandium] from comment #69)
> 
> Could QA test the builds below on various types of devices, and report what
> "SEGVHandler latency" they report on logcat?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 5393aa5a4df6/

1.ARMv6 LG Slider: Android 2.3.3
E/GeckoLinker( 1715): SEGVHandler latency: 44999
2.ARMv6 Alcatel One Touch 903: Android 2.3.6
E/GeckoLinker( 1529): SEGVHandler latency: 97154
3.LG-P500: Android 2.2
E/GeckoLinker( 2525): SEGVHandler latency: 58333
4. HTC Desire Z A7272: Android 2.3.3
E/GeckoLinker( 3246): SEGVHandler latency: 30517

Comment 74

[u421692]

1. HTC Desire A8181(Bravo)(Android 2.2.2)
E/GeckoLinker( 1761): SEGVHandler latency: 30518  
2. HTC Desire S(Android 2.3.3)
E/GeckoLinker( 4449): SEGVHandler latency: 30517

Comment 75

[Aaron Train [:aaronmt]]

Mike, is there anything to make from this data thus far?

Need-info on Tony to check the same thing on the office Sony Xperia Z

Comment 76

[Mike Hommey [:glandium]]

(In reply to Aaron Train [:aaronmt] from comment #75)
> Mike, is there anything to make from this data thus far?

This is useful data, and I think it is enough... except for the data on a stock rom xperia Z.

Comment 77

[Tony Chung [:tchung]]

moving ni? to kevin for monday to look at.   the device i have here seems bricked in a busted CM state, and i dont know how to restore it to android.

Kevin, i left the device on your desk.

Comment 78

[Ryan VanderMeulen [:RyanVM]]

(In reply to Mike Hommey [:glandium] from comment #68)
> I guess this is the reasonable thing to do until we have a validated
> workaround.

https://hg.mozilla.org/releases/mozilla-beta/rev/68bea7ee703d

Comment 79

[Kevin Brosnan [Ex-Mozilla]]

Sony Xperia Z Android 4.2.2 10-18 00:12:27.234: E/GeckoLinker(22228): SEGVHandler latency: 3662110

Comment 80

[Mike Hommey [:glandium]]

Can someone test this build on an xperia z with cyanogenmod?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-801b1d41aa61/try-android/fennec-27.0a1.en-US.android-arm.apk

Comment 81

[Mike Hommey [:glandium]]

Attachment: Disable on-demand decompression when latency to get into segfault handlers is too high

Comment 82

[Marcin Norest]

(In reply to Mike Hommey [:glandium] from comment #80)
> Can someone test this build on an xperia z with cyanogenmod?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 801b1d41aa61/try-android/fennec-27.0a1.en-US.android-arm.apk

This version works (like stable) on Xperia Z with CM 10.2 (android 4.3.1).

Comment 83

[:Cykesiopka]

(In reply to Marcin Norest from comment #82)
> (In reply to Mike Hommey [:glandium] from comment #80)
> > Can someone test this build on an xperia z with cyanogenmod?
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> > 801b1d41aa61/try-android/fennec-27.0a1.en-US.android-arm.apk
> 
> This version works (like stable) on Xperia Z with CM 10.2 (android 4.3.1).

Same here.
"SEGVHandler latency: 0" in logcat for this build, if it's still relevant...

Comment 84

[Mike Hommey [:glandium]]

(In reply to Marcin Norest from comment #82)
> This version works (like stable) on Xperia Z with CM 10.2 (android 4.3.1).

I guess this means it's not freezing for half a minute during startup?

Comment 85

[Nathan Froyd [:froydnj]]

Comment on attachment 818841 [details] [diff] [review]
Disable on-demand decompression when latency to get into segfault handlers is too high

Review of attachment 818841 [details] [diff] [review]:
-----------------------------------------------------------------

SIGSEGV handling is fun, part 6/n.

Comment 86

[Marcin Norest]

(In reply to Mike Hommey [:glandium] from comment #84)
> (In reply to Marcin Norest from comment #82)
> > This version works (like stable) on Xperia Z with CM 10.2 (android 4.3.1).
> 
> I guess this means it's not freezing for half a minute during startup?

Works fine, without freezing. After five seconds after first starting app, it shows the information about the stats & data already (previously during the freezing, after ~25 sec).
Browser after start is ready to work.

Comment 87

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6722e803c598

Comment 88

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6722e803c598

Comment 89

[Mike Hommey [:glandium]]

Comment on attachment 818841 [details] [diff] [review]
Disable on-demand decompression when latency to get into segfault handlers is too high

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 848764
User impact if declined: Extremely slow startup on some android devices
Testing completed (on m-c, etc.): Landed on m-c a couple days ago.
Risk to taking this patch (and alternatives if risky): The worst that can happen with this patch is on-demand decompression getting disabled on more devices than intended, which just means they would work like current release and beta, which have on-demand decompression disabled everywhere.
String or IDL/UUID changes made by this patch: None

Comment 90

[Mike Hommey [:glandium]]

(In reply to Mike Hommey [:glandium] from comment #89)
> Testing completed (on m-c, etc.): Landed on m-c a couple days ago.

Actually, I'm lying, it landed on m-i yesterday and was merged in m-c today.

Comment 91

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f1c2b046a201

Comment 92

[sviter33]

The same problem with Samsung p3100 and CyanogenMod 10.1.3. Nightly 37 didn't start with following log:

build.board: piranha
build.bootloader: unknown
build.brand: samsung
build.cpu_abi: armeabi-v7a
build.cpu_abi2: armeabi
build.device: espressorf
build.display: cm_p3100-userdebug 4.2.2 JDQ39E eng.jenkins.20130923.180436 test-keys
build.fingerprint: samsung/espressorfxx/espressorf:4.0.3/IML74K/P3100XWALE2:user/release-keys
build.hardware: espresso
build.host: cyanogenmod
build.id: JDQ39E
build.manufacturer: samsung
build.model: GT-P3100
build.product: espressorfxx
build.radio: unknown
build.serial: c080892a849ec21
build.tags: test-keys
build.time: 1379984718000
build.type: userdebug
build.user: jenkins
version.codename: REL
version.incremental: eng.jenkins.20130923.180436
version.release: 4.2.2
version.sdk_int: 17

12-10 14:46:23.080 F/GeckoLoader(13535): Couldn't load mozglue. Trying native library dir.
12-10 14:46:23.096 F/GeckoLoader(13535): Library doesn't exist when it should.
12-10 14:46:23.096 F/GeckoLoader(13535): Couldn't load /data/data/org.mozilla.fennec/lib/libmozglue.so: java.lang.UnsatisfiedLinkError: Cannot load library: load_library(linker.cpp:771): library "/data/data/org.mozilla.fennec/lib/libmozglue.so" not found
12-10 14:46:23.103 F/GeckoLoader(13535): Couldn't load /data/app-lib/org.mozilla.fennec/libmozglue.so: java.lang.UnsatisfiedLinkError: Cannot load library: load_library(linker.cpp:771): library "/data/app-lib/org.mozilla.fennec/libmozglue.so" not found
12-10 14:46:23.111 F/GeckoLoader(13535): Couldn't load /data/data/org.mozilla.fennec/lib/libmozglue.so: java.lang.UnsatisfiedLinkError: Cannot load library: load_library(linker.cpp:771): library "/data/data/org.mozilla.fennec/lib/libmozglue.so" not found

Comment 93

[Kartikaya Gupta (email:[e-mail])]

This bug has been resolved so it would be best to file a new bug for the issue you are seeing. It might be related to the recent split APK changes that were made.