578952 - Page doesn't load when electrolysis is enabled

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Johan Euphrosine]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6
Build Identifier: Mozilla/5.0 (X11; Linux armv7l; fr; rv:2.0b2pre) Gecko/20100715 Namoroka/4.0b2pre Fennec/2.0a1pre

Page doesn't load when browser.tabs.remote is true.
Page load when browser.tabs.remote is false

Reproducible: Always

Steps to Reproduce:
1. Install After installing http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mobile-trunk-maemo5-gtk/fennec_2.0~a1~20100715010459_armel.deb
2. Type google.com in the address bar
3. Hit enter
Actual Results:  
It shows a checker board

Expected Results:  
It should show google.com

If settings browser.tabs.remote to 'false' in about:config, the page does load.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

I found this same problem with a local build of Fennec. I "fixed" the issue by removing lines 12 and 13 here:
http://hg.mozilla.org/build/buildbot-configs/file/4f354feb8b2e/mozilla2/mobile/maemo5-gtk/mobile-browser/nightly/mozconfig#l12

After a rebuild, then pages load fine - no checkerboard

Comment 2

[(not currently active) Ted Mielczarek]

Could be some bad interaction with Breakpad and content processes. We don't have crash reporting hooked up yet to content processes (AFAIK), and MOZILLA_OFFICIAL controls whether crash reporting is enabled by default at runtime:
http://mxr.mozilla.org/mobile-browser/source/app/application.ini#23

Comment 3

[Martijn Wargers (dead)]

This bug basically makes it impossible to test Fennec on the n900, currently.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Are both processes being built the same way? I mean is there something that could be incompatible? The content process doesn't seem to even want to start talking to the main process

Do the symbols somehow mess up the IPC protocol?

Comment 5

[(not currently active) Ted Mielczarek]

I think it's the MOZILLA_OFFICIAL, not the symbols. Try this experiment:
Get a build that's failing to load pages. In the shell, export MOZ_CRASHREPORTER_DISABLE=1. Run the build, and see if it works. If so, the problem only appears when crash reporting is enabled.

Comment 6

[Stuart Parmenter]

Benjamin, do you know who can help with this bug?

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #5)
> I think it's the MOZILLA_OFFICIAL, not the symbols. Try this experiment:
> Get a build that's failing to load pages. In the shell, export
> MOZ_CRASHREPORTER_DISABLE=1. Run the build, and see if it works. If so, the
> problem only appears when crash reporting is enabled.

Disabling the crashreporter _did_ make remote pages load

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: CrashReporter::GetEnabled() really means is the *in-process* crashreporter enabled (for now)

I poked back into this code to prepare a todo list for enabling crash reporting for content processes, but I had forgotten that the exception handler is set up automatically when launching subprocesses.  The hang is from ARENA_POISON_init() trying to AnnotateCrashReport() because GetEnabled() is true, but crashing because the annotation code isn't initialized (since it's OOP).  We'll want that eventually, but for now this semi-workaround patch just makes GetEnabled() mean the same thing as for desktop firefox.

This doesn't "hook up" the crashreporter: we still need some code for content processes like this [1], this [2], and probably this [3].

[1] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#134
[2] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#262
[3] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#190

Comment 9

[(not currently active) Ted Mielczarek]

Comment on attachment 459733 [details] [diff] [review]
CrashReporter::GetEnabled() really means is the *in-process* crashreporter enabled (for now)

Do we want this as a permanent behavior switch? Currently the other API bits (like annotating) don't work in subprocesses anyway, so there's probably not much point.

r=me

Comment 10

[Benjamin Smedberg]

Hrm, we're probably going to want annotations to work, remoting them to the chrome process. But for now, let's do whatever is expedient.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed:
http://hg.mozilla.org/mozilla-central/rev/bcae411bc333

Comment 12

[Joel Maher ( :jmaher ) (UTC -8)]

it seems that with this build I am unable to get a webpage to load:
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-06-26-02-mobile-trunk-maemo5-gtk/

this is specific to a n900 as I can get it loaded on a linux desktop build.

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #12)
> it seems that with this build I am unable to get a webpage to load:
> http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-06-26-02-mobile-trunk-maemo5-gtk/
> 
> this is specific to a n900 as I can get it loaded on a linux desktop build.

Works fine for me using the build here:
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-maemo5-gtk/fennec-2.0a1pre.multi.linux-gnueabi-arm.tar.bz2