Closed Bug 907917 Opened 11 years ago Closed 3 years ago

Adding a new search provider then opening the customise menu in settings causes an assertion failure.

Categories

(Firefox for Android Graveyard :: General, defect, P5)

ARM
Android
defect

Tracking

(fennec+)

RESOLVED INCOMPLETE
Tracking Status
fennec + ---

People

(Reporter: ckitching, Unassigned)

Details

(Keywords: assertion)

STR:

Open a debug build of Fennec.
Navigate to settings->Customise.
Observe the lack of explosions.
Navigate to duckduckgo.com
Long-tap the search input.
Select "Add search provider"
Select "OK"
Navigate to settings->Customise again.
Observe the app crashing with:

"08-21 13:52:40.769: ASSERT/MOZ_Assert(14144): Assertion failure: !mAsyncExecutionThread (AsyncClose has not been invoked on this connection!), at /home/chris/Fennec/Fennec/storage/src/mozStorageConnection.cpp:497"
Keywords: assertion
Does this happen with the old search management UI on aurora?
tracking-fennec: --- → ?
Assignee: nobody → ckitching
tracking-fennec: ? → 26+
(In reply to :Margaret Leibovic from comment #1)
> Does this happen with the old search management UI on aurora?

Yup. I can also reproduce it on release (Debug build thereof). (To be exact - this one:
http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-release-android-debug/1376734458/fennec-23.0.en-US.android-arm.apk
)

This fault isn't going to cause noticeable symptoms to users of non-debug builds, but does represent a programming mistake (An omission to close a resource) somewhere in the C++ code.

The symptoms are slightly different with the new UI due to the way the SIGSEGV handler seems to optimistically restart the app and carry on in case of problems. This seems to lead to a Java NPE being spat out when the preferences activity attempts to resume to find that some information that once was set has now vanished.
Or something.

While I could investigate this, I don't think I'm the best choice of person to do so (As it's not a regression from my latest patch, nor is it in code I have thus far worked on.)
If this problem is DEBUG only, I don't think we need to track for Fx26
(In reply to Mark Finkle (:mfinkle) from comment #3)
> If this problem is DEBUG only, I don't think we need to track for Fx26

Sounds sensible. Been neglecting this one since it's not obvious to fix and not that important.
tracking-fennec: 26+ → ?
tracking-fennec: ? → +
Not going to have time to look at this any time soon...
Assignee: chriskitching → nobody
filter on [mass-p5]
Priority: -- → P5
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.