Closed Bug 614801 Opened 9 years ago Closed 9 years ago

Fennec 4.0b3pre Crash Report [@ mozilla::dom::ContentParent::Observe ]

Categories

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

ARM
Android
defect
Not set
critical

Tracking

(fennec2.0b3+)

VERIFIED FIXED
Tracking Status
fennec 2.0b3+ ---

People

(Reporter: anamaria.moldovan, Unassigned)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101117 Firefox/4.0b8pre
Build Identifier: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b8pre) Gecko/20101125 Firefox/4.0b8pre Fennec /4.0b3pre

Fennec crashes when switching from portrait to landscape mode and vice-versa. 

Devices: HTC Desire, Motorola Droid2

Reproducible: Always

Steps to Reproduce:
1. Start Fennec in portrait mode.
2. Rotate the device into landscape mode.

Actual Results:  
Fennec crashes with: http://crash-stats.mozilla.com/report/index/58cfbdc0-d1bc-4d7e-aecf-d125e2101125

Expected Results:  
The browser should switch to landscape mode.


Same happens if you start Fennec in landscape mode and then rotate the device into portrait mode.
OS: Other → Android
Hardware: Other → ARM
We're crashing because we're still initializing the prefs service and end up with a null pointer to it in the observer.  It's not hard to avoid the crash, but then we won't be able to send the update to the child and we'll be out of sync.
This needs to be block beta3.

That patch *really* doesn't look like the right fix.  Why did this just start happening?  Why does the pref service appear to be reinitializing itself on orientation changes, of all things?  Really really need a bisect here.
tracking-fennec: --- → ?
We just changed the start up logic yesterday. are we getting a new intent on orientation changes?
Duplicate of this bug: 614870
STR in bug 614870!
(In reply to comment #6)
> STR in bug 614870!

And in comment 0!  /me is embarrassed.
i see this all of thr time.  we should block beta on this.
tracking-fennec: ? → 2.0b3+
This was caused by bug 607939.  I reverted the changeset.  Marking fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Keywords: crash, topcrash
(In reply to comment #9)
> This was caused by bug 607939.  I reverted the changeset.  Marking fixed.

Bug 607939 landed again. Does that mean this crash will happen again?
(In reply to comment #10)
> (In reply to comment #9)
> > This was caused by bug 607939.  I reverted the changeset.  Marking fixed.
> 
> Bug 607939 landed again. Does that mean this crash will happen again?

it landed with a fix for this
VERIFIED FIX on Devices: Motorola Droid 2, HTC Desire.

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b8pre)
Gecko/20101129 Firefox/4.0b8pre Fennec /4.0b3pre
Status: RESOLVED → VERIFIED
I'm still getting this crash fairly regularly, albeit not by rotating my phone.  Looking at the code <http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#359>, the patch attached to this bug has not landed.  I'm not sure which fix comment 11 is talking about, but this bug is not fixed yet at any rate.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Crashes at mozilla::dom::ContentParent::Observe *not* triggered by orientation changes would seem to be a different problem, worthy of a separate bug.
(In reply to comment #14)
> Crashes at mozilla::dom::ContentParent::Observe *not* triggered by orientation
> changes would seem to be a different problem, worthy of a separate bug.

Not really, I get the exact same stack.  The underlying problem of this crash has not been fixed indeed.
That's really scary.  Sounds like the fix for bug 607939 may not have been complete then.
Strange, crash-stats isn't showing any crashes with this signature since the 26th.
(In reply to comment #17)
> Strange, crash-stats isn't showing any crashes with this signature since the
> 26th.

I have at least a couple in my about:crashes.  Do you need me to dig up their IDs?

(In reply to comment #16)
> That's really scary.  Sounds like the fix for bug 607939 may not have been
> complete then.

Sorry for being naive, but I don't see what that fix could possibly have to do with this crash!
(In reply to comment #18)
> (In reply to comment #16)
> > That's really scary.  Sounds like the fix for bug 607939 may not have been
> > complete then.
> 
> Sorry for being naive, but I don't see what that fix could possibly have to do
> with this crash!

See comment 9 and comment 11.
Ehsan, yes.  dig up their ID, file a new bug, and lets do the investigation there.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Depends on: 615458
OK, filed bug 615458.
No longer depends on: 615458
Duplicate of this bug: 615458
VERIFIED FIXED on:

Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:7.0a1) Gecko/20110530 Firefox/7.0a1 Fennec/7.0a1 

Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a2) Gecko/20110529 Firefox/6.0a2 Fennec/6.0a2 

Device: HTC Desire Z (Android 2.2)
Status: RESOLVED → VERIFIED
Crash Signature: [@ mozilla::dom::ContentParent::Observe ]
You need to log in before you can comment on or make changes to this bug.