Closed Bug 1390140 Opened 2 years ago Closed 2 years ago

Crash when removing history entry

Categories

(Firefox for Android :: Awesomescreen, defect)

55 Branch
All
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 57
Tracking Status
fennec + ---
firefox55 - wontfix
firefox56 - verified
firefox57 - verified

People

(Reporter: massic80, Assigned: JanH)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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)
Do you have a crash report from about:crashes you can link to?
Flags: needinfo?(massic80)
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
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) ]
[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: --- → ?
Keywords: crash
OS: Unspecified → Android
Hardware: Unspecified → All
Version: 57 Branch → 55 Branch
With only one crash, I don't think it is worth tracking.
Please resubmit if it starts to spike.
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
Hi :jwu
Do you have any idea about this?
Flags: needinfo?(topwu.tw)
Assignee: nobody → jh+bugzilla
Duplicate of this bug: 1393595
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+
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
Flags: needinfo?(topwu.tw)
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?
https://hg.mozilla.org/mozilla-central/rev/2cbd34e59b97
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
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+
tracking-fennec: ? → +
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 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-
You need to log in before you can comment on or make changes to this bug.