Closed Bug 945327 Opened 11 years ago Closed 11 years ago

crash in libc.so@0x22048 / libc.so@0x21f90 - Android 4.4 Nexus devices - Downloading files

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox25 wontfix, firefox26 wontfix, firefox27+ fixed, firefox28+ fixed, firefox29+ fixed, fennec+)

Status:
RESOLVED FIXED
Milestone:
Firefox 29
Tracking Flags:
Tracking Status
firefox25 --- wontfix
firefox26 --- wontfix
firefox27 + fixed
firefox28 + fixed
firefox29 + fixed
fennec + ---

People

(Reporter: kbrosnan, Assigned: jchen)

References

Details

(Keywords: crash, topcrash, Whiteboard: [native-crash])

Crash Data

Attachments

(4 files, 1 obsolete file)

Screenshot of duplicate file names
(deleted), image/png
Details
gdb output
(deleted), text/plain
Details
logcat output
(deleted), text/x-vhdl
Details
Improve local ref management in AndroidBridge (v1.1)
(deleted), patch
jchen
: review+
bajaj
: approval-mozilla-aurora+
bajaj
: approval-mozilla-beta+
Details | Diff | Splinter Review
This bug was filed from the Socorro interface and is report bp-f6c44ac6-311d-4f1a-a60e-078ee2131201. ============================================================= Crash on the older Nexus 7 2012 when running Android 4.4, http://en.wikipedia.org/wiki/Nexus_7_%282012_version%29
tracking-fennec: --- → ?
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected
tracking-firefox27: --- → ?
tracking-firefox28: --- → ?
tracking-firefox29: --- → ?
Some of the crash comments indicate downloading could be leading to crashes so maybe we can get some testcases on Kit Kat around downloads?
Flags: needinfo?(kbrosnan)
Keywords: steps-wanted
tracking-fennec: ? → +
Attached image Screenshot of duplicate file names (deleted) —
I downloaded the same file repeatedly and eventually Firefox gave the file the same name. This crashed Firefox.
Flags: needinfo?(kbrosnan)
Keywords: steps-wanted
Renominating for tracking Fennec and to get an assignee.
tracking-fennec: + → ?
Crash Signature: [@ libc.so@0x22048] → [@ libc.so@0x22048] [@ libc.so@0x21f90]
Summary: crash in libc.so@0x22048 - Nexus 7 2012 Android 4.4 → crash in libc.so@0x22048 / libc.so@0x21f90 - Android 4.4 Nexus devices - Downloading files
This is reproducible on the ART run time as well
Crash Signature: [@ libc.so@0x22048] [@ libc.so@0x21f90] → [@ libc.so@0x22048] [@ libc.so@0x21f90] [@ libart.so@0x195657]
Attached file gdb output (deleted) —
Downloaded about 50 of [1] under gdb and produced the attached output. Ran `where` and `list` at the end. Note color codes are included. In particular: > #0 0x68817342 in mozalloc_abort (msg=0x6b8fab38 "[9119] ###!!! ABORT: > Failed to push local JNI frame: 'ret == 0', file ../../dist/include > /AndroidBridge.h, line 515") at /home/mcomella/dev/fig/memory/mozalloc > /mozalloc_abort.cpp:30 [1]: https://upload.wikimedia.org/wikipedia/commons/d/d3/IU_at_the_Life_Style_Awards_2011_%282%29.jpg
Attached file logcat output (deleted) —
For run associated with comment 6, dumped a few minutes after the crash.
Jim, this looks like a mismatched JNI Push/PopFrame, can you dig in?
Assignee: nobody → nchen
tracking-fennec: ? → +
I was able to reproduce this on my Nexus 4, and I see several cases where local refs can be leaked in AndroidBridge. Right now I'm doing an audit of AndroidBridge methods.
Status: NEW → ASSIGNED
Seems to fix the crash on my Nexus 4 using mcomella's STR.
Attachment #8355594 - Flags: review?(blassey.bugs)
Comment on attachment 8355594 [details] [diff] [review] Improve local ref management in AndroidBridge (v1) Review of attachment 8355594 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/android/AndroidBridge.cpp @@ +337,5 @@ > aHandlersArray->AppendElement(app, false); > if (aDefaultApp && isDefault.Length() > 0) > *aDefaultApp = app; > + > + aJNIEnv->PopLocalFrame(NULL); why not use an AutoLocalJNIFrame?
Attachment #8355594 - Flags: review?(blassey.bugs) → review+
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #11) > Comment on attachment 8355594 [details] [diff] [review] > Improve local ref management in AndroidBridge (v1) > > Review of attachment 8355594 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: widget/android/AndroidBridge.cpp > @@ +337,5 @@ > > aHandlersArray->AppendElement(app, false); > > if (aDefaultApp && isDefault.Length() > 0) > > *aDefaultApp = app; > > + > > + aJNIEnv->PopLocalFrame(NULL); > > why not use an AutoLocalJNIFrame? Good idea. https://hg.mozilla.org/integration/mozilla-inbound/rev/d7dfd3217a54
Attachment #8355594 - Attachment is obsolete: true
Attachment #8356177 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/d7dfd3217a54
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
status-firefox29: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8356177 [details] [diff] [review] Improve local ref management in AndroidBridge (v1.1) [Approval Request Comment] Bug caused by (feature/regressing bug #): N/A User impact if declined: Crash doing certain tasks such as downloading files Testing completed (on m-c, etc.): Locally, m-c Risk to taking this patch (and alternatives if risky): Small; patch only fixes previous bugs and does not alter functionality String or IDL/UUID changes made by this patch: None
Attachment #8356177 - Flags: approval-mozilla-beta?
Attachment #8356177 - Flags: approval-mozilla-aurora?
Attachment #8356177 - Flags: approval-mozilla-beta?
Attachment #8356177 - Flags: approval-mozilla-beta+
Attachment #8356177 - Flags: approval-mozilla-aurora?
Attachment #8356177 - Flags: approval-mozilla-aurora+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: