Closed
Bug 1390140
Opened 7 years ago
Closed 7 years ago
Crash when removing history entry
Categories
(Firefox for Android Graveyard :: Awesomescreen, defect)
Tracking
(fennec+, firefox55- wontfix, firefox56- verified, firefox57- verified)
RESOLVED
FIXED
Firefox 57
People
(Reporter: massic80, Assigned: JanH)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
59 bytes,
text/x-review-board-request
|
Grisha
:
review+
gchang
:
approval-mozilla-beta+
jcristau
:
approval-mozilla-release-
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170810180547 Steps to reproduce: Searched for an history entry (e.g. "go" for Google) by using URL bar. I long-tapped one of the found entries. I chose "Remove / Delete" (I have the Italian version) from the context menu. Actual results: Firefox freezed and crashed. I reproduced it for several versions. Expected results: The entry should have been removed from the browser history (and Sync)
Assignee | ||
Comment 1•7 years ago
|
||
Do you have a crash report from about:crashes you can link to?
Flags: needinfo?(massic80)
Reporter | ||
Comment 2•7 years ago
|
||
Here it is: https://crash-stats.mozilla.com/report/index/9e1a2921-0631-441d-9ada-29c780170814
Flags: needinfo?(massic80)
Comment 3•7 years ago
|
||
Weird things start to happen when I try steps in Comment 1. 08-14 21:07:14.801 5490 5611 I zygote : Alloc concurrent copying GC freed 5(16KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 383MB/384MB, paused 258us total 497.209ms 08-14 21:07:14.801 5490 5527 I zygote : WaitForGcToComplete blocked for 982.586ms for cause Alloc 08-14 21:07:14.801 5490 5527 I zygote : Starting a blocking GC Alloc 08-14 21:07:14.801 5490 5520 I zygote : WaitForGcToComplete blocked for 497.151ms for cause Alloc 08-14 21:07:14.801 5490 5520 I zygote : Starting a blocking GC Alloc 08-14 21:07:14.801 5490 5520 I zygote : Starting a blocking GC Alloc 08-14 21:07:14.801 5490 5499 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:14.801 5490 5611 I zygote : Forcing collection of SoftReferences for 16B allocation 08-14 21:07:14.801 5490 5611 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:14.802 5490 5527 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:15.293 5490 5520 I zygote : Clamp target GC heap from 389MB to 384MB 08-14 21:07:15.293 5490 5520 I zygote : Alloc concurrent copying GC freed 57(14KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 383MB/384MB, paused 164us total 492.301ms 08-14 21:07:15.293 5490 5499 I zygote : WaitForGcToComplete blocked for 986.023ms for cause Alloc 08-14 21:07:15.293 5490 5499 I zygote : Starting a blocking GC Alloc 08-14 21:07:15.294 5490 5611 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:15.301 5490 5527 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:15.301 5490 5520 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:15.771 5490 5499 I zygote : Clamp target GC heap from 389MB to 384MB 08-14 21:07:15.771 5490 5499 I zygote : Alloc concurrent copying GC freed 7(16KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 383MB/384MB, paused 387us total 477.030ms 08-14 21:07:15.771 5490 5611 I zygote : WaitForGcToComplete blocked for 969.417ms for cause Alloc 08-14 21:07:15.771 5490 5611 I zygote : Starting a blocking GC Alloc 08-14 21:07:15.771 5490 5527 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:15.771 5490 5520 I zygote : Waiting for a blocking GC Alloc 08-14 21:07:16.809 5490 5611 I zygote : Clamp target GC heap from 389MB to 384MB 08-14 21:07:16.809 5490 5611 I zygote : Alloc concurrent copying GC freed 70(19KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 383MB/384MB, paused 295us total 1.038s 08-14 21:07:16.809 5490 5527 I zygote : WaitForGcToComplete blocked for 2.007s for cause Alloc 08-14 21:07:16.809 5490 5527 I zygote : Starting a blocking GC Alloc 08-14 21:07:16.809 5490 5520 I zygote : WaitForGcToComplete blocked for 1.508s for cause Alloc 08-14 21:07:16.809 5490 5520 I zygote : Starting a blocking GC Alloc 08-14 21:07:16.809 5490 5520 I zygote : Starting a blocking GC Alloc 08-14 21:07:16.810 5490 5611 W zygote : Throwing OutOfMemoryError "Failed to allocate a 16 byte allocation with 494256 free bytes and 482KB until OOM, max allowed footprint 402653184, growth limit 402653184; failed due to fragmentation (largest possible contiguous allocation 0 bytes)" ... and eventually we crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•7 years ago
|
Crash Signature: [@ java.util.concurrent.TimeoutException: com.android.internal.os.BinderInternal$GcWatcher.finalize() timed out after 10 seconds at java.lang.Object.notify(Native Method) ]
Assignee | ||
Comment 4•7 years ago
|
||
[Tracking Requested - why for this release]: Removing a history entry (that isn't also a bookmark) via our awesomebar search results crashes Firefox. This happens when removing a history search result that isn't also a bookmark (https://dxr.mozilla.org/mozilla-central/rev/7ff4c2f1fe11f6b98686f783294692893b1e1e8b/mobile/android/base/java/org/mozilla/gecko/home/HomeFragment.java#539). Bug 1232439 changed the implementation to delete bookmarks by ID (https://dxr.mozilla.org/mozilla-central/rev/7ff4c2f1fe11f6b98686f783294692893b1e1e8b/mobile/android/base/java/org/mozilla/gecko/home/HomeFragment.java#577) instead of by URL as was formerly the case, but doesn't handle the case of being handed an invalid bookmark ID (0 in this case).
Blocks: 1232439
tracking-fennec: --- → ?
status-firefox55:
--- → affected
status-firefox56:
--- → affected
status-firefox57:
--- → affected
tracking-firefox55:
--- → ?
tracking-firefox56:
--- → ?
tracking-firefox57:
--- → ?
Keywords: crash
OS: Unspecified → Android
Hardware: Unspecified → All
Version: 57 Branch → 55 Branch
Comment 5•7 years ago
|
||
With only one crash, I don't think it is worth tracking. Please resubmit if it starts to spike.
Assignee | ||
Comment 6•7 years ago
|
||
Note that this is an OOM crash, so - crash reports might fail to submit at all - those crash reports that do get through will be spread across a number of different crash signatures
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → jh+bugzilla
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 11•7 years ago
|
||
mozreview-review |
Comment on attachment 8900414 [details] Bug 1390140 - Account for bookmark ID being <null> when populating BrowserSearch's HomeContextMenuInfo. https://reviewboard.mozilla.org/r/171760/#review177688 Ah, good catch.
Attachment #8900414 -
Flags: review?(gkruglov) → review+
Comment 12•7 years ago
|
||
Pushed by gkruglov@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2cbd34e59b97 Account for bookmark ID being <null> when populating BrowserSearch's HomeContextMenuInfo. r=Grisha
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(topwu.tw)
Assignee | ||
Comment 13•7 years ago
|
||
Comment on attachment 8900414 [details] Bug 1390140 - Account for bookmark ID being <null> when populating BrowserSearch's HomeContextMenuInfo. Approval Request Comment [Feature/Bug causing the regression]: Awesomebar search, uncovered by bug 1232439. [User impact if declined]: When searching local history from the awesomebar, attempting to remove a search history result that isn't also a bookmark will a) not work and b) eventually crash Firefox. [Is this code covered by automated tests?]: No. [Has the fix been verified in Nightly?]: Verified locally. [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: Just adding an explicit <null> check for the bookmark ID retrieved from our database, so we turn this into the correct invalid bookmark ID (-1) expected by the rest of our code. [String changes made/needed]: None.
Attachment #8900414 -
Flags: approval-mozilla-release?
Attachment #8900414 -
Flags: approval-mozilla-beta?
Comment 14•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2cbd34e59b97
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Updated•7 years ago
|
Comment 15•7 years ago
|
||
Comment on attachment 8900414 [details] Bug 1390140 - Account for bookmark ID being <null> when populating BrowserSearch's HomeContextMenuInfo. Fix an awesomebar search issue. Beta56+.
Attachment #8900414 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Updated•7 years ago
|
tracking-fennec: ? → +
Comment 16•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/1f1e924b5acd
Comment 17•7 years ago
|
||
Verified following the steps provided in Comment 1 on a Nexus 5 (Android 6.0.1), the issue was not reproducible in 56.0b7 and Nightly (2017-08-29). Marking as verified.
Comment 18•7 years ago
|
||
Comment on attachment 8900414 [details] Bug 1390140 - Account for bookmark ID being <null> when populating BrowserSearch's HomeContextMenuInfo. no more 55 dot releases planned, m-r is about to become 56.
Attachment #8900414 -
Flags: approval-mozilla-release? → approval-mozilla-release-
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•