This bug was filed from the Socorro interface and is report bp-636976cd-0418-42e1-9a99-6768a2130911. ============================================================= STR: 1. Open the Email app 2. Configure a Active sync email account Expected: 2. The Email app will not crash Actual: 2. The Email app crashes

I reproduced this on: Gecko http://hg.mozilla.org/mozilla-central/rev/f9e8e8ce552c Gaia ebbb325958c66c3e68e1f190472d5f6e9076d83a BuildID 20130911040201 Version 26.0a1 This is reproducible in our Gaia-UI-Automation build First build that failed: http://qa-selenium.mv.mozilla.com:8080/job/b2g.unagi.mozril.gaia.master.ui/192 (Sep 11, 2013 5:57:15 AM)

Do we have a stack?

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2) > Do we have a stack? Here's the stack from the crash report URL. We could try to get more if need be. Frame Module Signature Source 0 @0x41edd4cc 1 libxul.so JSObject::putProperty(js::ExclusiveContext*, JS::Handle<JSObject*>, JS::Handle<int>, bool (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<int>, JS::MutableHandle<JS::Value>), bool (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<int>, bool, JS::MutableHandle<JS::Value>), unsigned int, unsigned int, unsigned int, int) js/src/vm/Shape.cpp 2 libxul.so DefinePropertyOrElement js/src/jsobj.h 3 libxul.so js::baseops::SetPropertyHelper(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<int>, unsigned int, JS::MutableHandle<JS::Value>, bool) js/src/jsobj.cpp 4 libxul.so Interpret js/src/vm/Interpreter.cpp 5 libxul.so js::Invoke js/src/vm/Interpreter.cpp 6 libxul.so JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::Value*) js/src/jsapi.cpp 7 libxul.so mozilla::dom::workers::EventListenerManager::DispatchEvent(JSContext*, mozilla::dom::workers::EventTarget const&, JSObject*, mozilla::ErrorResult&) const dom/workers/EventListenerManager.cpp 8 libxul.so mozilla::dom::EventTargetBinding_workers::dispatchEvent dom/workers/EventTarget.h 9 libxul.so mozilla::dom::EventTargetBinding_workers::genericMethod /builds/slave/b2g_m-cen_unagi_eng_ntly-00000/build/objdir-gecko/dom/bindings/EventTargetBinding.cpp 10 libxul.so js::Invoke js/src/jscntxtinlines.h 11 libxul.so JS_CallFunctionName(JSContext*, JSObject*, char const*, unsigned int, JS::Value*, JS::Value*) js/src/jsapi.cpp 12 libxul.so mozilla::dom::workers::events::DispatchEventToTarget(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, bool*) dom/workers/Events.cpp 13 libxul.so EventRunnable::WorkerRun dom/workers/XMLHttpRequest.cpp 14 libxul.so mozilla::dom::workers::WorkerRunnable::Run() dom/workers/WorkerPrivate.cpp 15 libxul.so mozilla::dom::workers::WorkerPrivate::DoRunLoop(JSContext*) dom/workers/WorkerPrivate.cpp 16 libxul.so WorkerThreadRunnable::Run dom/workers/RuntimeService.cpp 17 libxul.so nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 18 libxul.so NS_ProcessNextEvent(nsIThread*, bool) /builds/slave/b2g_m-cen_unagi_eng_ntly-00000/build/objdir-gecko/xpcom/build/nsThreadUtils.cpp 19 libxul.so nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp 20 libnss3.so _pt_root nsprpub/pr/src/pthreads/ptthread.c 21 libc.so __thread_entry bionic/libc/bionic/pthread.c 22 libc.so pthread_create bionic/libc/bionic/pthread.c 23 @0x43eb4002

If the regression happened due to a change in DOM Workers, then this was either caused by bug 888347 or bug 901291.

Ok, might be a JS engine bug. nbp is at the work week, maybe you guys can get this in a debugger with him?

(In reply to Jason Smith [:jsmith] from comment #4) > If the regression happened due to a change in DOM Workers, then this was > either caused by bug 888347 or bug 901291. Both seem unlikely, the former only changes how we shut down and the latter isn't actually being used yet.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5) > Ok, might be a JS engine bug. nbp is at the work week, maybe you guys can > get this in a debugger with him? Yup, confirmed it with nbp in person. Moving to JS engine component then.

That means this was caused by something that landed yesterday: https://bugzilla.mozilla.org/buglist.cgi?f1=cf_blocking_b2g&list_id=7882420&o1=substring&resolution=FIXED&chfieldto=Now&chfield=bug_status&query_format=advanced&chfieldfrom=-1d&component=JavaScript%20Engine&product=Core

We should bisect this down to the specific regressing changeset and back it out. Putting regressionwindow-wanted for bisection.

Verified manually : does not occur on 9/10 build, does occur on 9/11 build; awesome catch Florin! 9/11 http://hg.mozilla.org/mozilla-central/rev/f9e8e8ce552c 9/10 http://hg.mozilla.org/mozilla-central/rev/be1053dc223b https://git.mozilla.org/?p=releases/gecko.git;a=commit;h=a6fc46a7074fbebae65a49d87c85a2cbbbf8dc06 ; does not crash hg : 6bff7c027874 https://git.mozilla.org/?p=releases/gecko.git;a=commit;h=f11fc41386de5e2a7c5547a84b69d418f5879c44 ; crashes hg : b72836807987 https://git.mozilla.org/?p=releases/gecko.git;a=commit;h=aa9de4fcf11c9cebf869528a2c8066220b36a9b5 ; crashes hg : 315cc4fb111a

Naoki - I can't follow the results in comment 11. What's the regressing changeset?

I don't think the regressing changeset in comment 11 is right. We probably should retry doing this with HG, since the commit dates appear to be off on git.mozilla.org.

Naoki, do you have a mozilla-central and mozilla-inbound regression window?

(In reply to Jan de Mooij [:jandem] from comment #14) > Naoki, do you have a mozilla-central and mozilla-inbound regression window? What you see on comment 11 is what we ended up getting - which apparently wasn't the right regression window. We're hitting some difficulty since we don't typically get regression windows down to a changeset on B2G (usually down to a day), as we don't have builds on a per changeset basis (which results in manual generation of builds, which only a very small group of QAs know how to do). Is someone on the JS team able to help with a bisection? We really need to get this resolved asap, as this is blocking testing of the email application.

I'm getting my B2G repos updated and linux build going. I'll post as soon as I'm able to get a viable build that can be flashed onto a device and works. I should be able to help bisect after that.

To note: jsmith and I had talked about this in person at the work week. The changeset seems odd to both of us. I had used a mozilla-central build; not a mozilla-inbound. I don't have a mozilla-inbound changeset at this moment in time. Mozilla central github repo: https://git.mozilla.org/?p=releases/gecko.git;a=commit;h=a6fc46a7074fbebae65a49d87c85a2cbbbf8dc06 ; does not crash hg : 6bff7c027874 https://git.mozilla.org/?p=releases/gecko.git;a=commit;h=f11fc41386de5e2a7c5547a84b69d418f5879c44 ; crashes [OOM?] hg : b72836807987

I did a build for an unagi and flashed it, but I can't replicate the issue because wifi isn't working on the device. I suspect this is because I built off the wrong branch, and should have picked up a more recent branch. Going to rebuild and try replicating the issue.

(In reply to Kannan Vijayan [:djvj] from comment #18) > I did a build for an unagi and flashed it, but I can't replicate the issue > because wifi isn't working on the device. You can work around it by using wpa_cli on the phone to setup the wifi: $ adb shell % wpa_cli > add_network 0 > set_network 0 ssid "FooBar" > set_network 0 psk "secretPsk" > enable_network 0

Turned out I was not building 1.2 proper. Got a build going with working wifi that seems to crash when I try to create an e-mail account. I sent in a crash report, but I don't know if this is the crash I'm looking for. How do I view crash reports on my local device?

(In reply to Kannan Vijayan [:djvj] from comment #20) > Turned out I was not building 1.2 proper. Got a build going with working > wifi that seems to crash when I try to create an e-mail account. I sent in > a crash report, but I don't know if this is the crash I'm looking for. > > How do I view crash reports on my local device? https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Getting_crashes_off_the_Device

We are able to launch the Email app w/o it immedately crashing, but if you sit on the inbox for long enough signed into a hotmail account the app crashes, which is why we sadly didn't catch it during smoke. :( I also was only able to repro right after connecting an email account then waiting on the inbox. If you need a logcat let me know and I'll try to get one for you. Here is the info we got: Crash ID/Link: https://crash-stats.mozilla.com/report/index/a032bb6b-ddfc-4335-acc6-7f52a2130918 Environmental Variables Device: Buri 1.3 mozRIL Build ID: 20130917180029 Gecko: http://hg.mozilla.org/mozilla-central/rev/53a2011a01b2 Gaia: 678c1d23150b0b9b037de9b2122fcccd75bdb6f5 Platform Version: 27.0a1

No longer a smoketest blocker - we're not seeing this on signup of the email account per comment 22, but we are still seeing the crash present.

(In reply to Jason Smith [:jsmith] from comment #23) > No longer a smoketest blocker - we're not seeing this on signup of the email > account per comment 22, but we are still seeing the crash present. Apparently this isn't right - it's not reproducing always in the smoketest, but it's greater than 50% reproducibility.

Using the latest 1.2 Buri build, I can repro this crash every time I try to setup a hotmail account - this bug really needs to be koi+ Gaia 88e73da95f1c550f2fb0572480a40c989d37c997 SourceStamp 46b216260c1d BuildID 20130920004004 Version 26.0a2

koi+. this is a smoketest, regression blocker that needs JS team to assist.

I'm having a heck of a time replicating this problem. I have a 1.2 build, but when I open the e-mail app it shows a blank white screen and is not responsive. I don't think it's a build problem as other builds from nearby colleagues show the same issue on Unagi. I'm building with BRANCH=v1.2 for unagi. I need help getting this replicated locally, can someone advise?

(In reply to Kannan Vijayan [:djvj] from comment #27) > I'm having a heck of a time replicating this problem. > > I have a 1.2 build, but when I open the e-mail app it shows a blank white > screen and is not responsive. I don't think it's a build problem as other > builds from nearby colleagues show the same issue on Unagi. > > I'm building with BRANCH=v1.2 for unagi. I need help getting this > replicated locally, can someone advise? Strange - that's not what we're seeing on production builds. Fabrice - Do you know why the issue Kannan is citing might be happening?

Building on hamachi hoping this goes away if I change device.

(In reply to Jason Smith [:jsmith] from comment #28) > > Strange - that's not what we're seeing on production builds. > > Fabrice - Do you know why the issue Kannan is citing might be happening? No, but I can repro on a Leo running 1.2 :(

Fabrice: is there a bug for this issue yet? Should I file?

(In reply to Kannan Vijayan [:djvj] from comment #31) > Fabrice: is there a bug for this issue yet? Should I file? I filed bug 919006

I found a master build that didn't have the e-mail problem in bug 919006. This master build (on a hamachi) doesn't crash on an ActiveSync account login. I successfully set up the account, got the inbox contents, and read my e-mail. Still working on getting a viable inari build going.

Inari build shows same screen white-out issue on e-mail.

Does this issue still need a regressionwindow-wanted? looks like a couple have been posted. Also if a window is still needed let me know, we can check only: Leo Buri Inari

(In reply to Darren from comment #35) > Does this issue still need a regressionwindow-wanted? looks like a couple > have been posted. > > Also if a window is still needed let me know, we can check only: > Leo > Buri > Inari We've technically already got a regression window down to a day, but what's being asked for here is a regression window down to a changeset. That requires generating custom builds to test this.

Since this deals with making a custom gecko build, I added QAregressexclude since we are not able to build custom Geckos. Also removed myself as QA contact.

I finally managed to get a 1.3 build with an e-mail app that didn't suffer the "blank white screen" issue. That said, this bug doesn't reproduce for me. I've configured and used active sync accounts in many different variations: 1. Newly created live.com account (a few days old, with only a few e-mails in inbox) 2. Pre-existing gmail.com account (long-term account with lots of e-mails) 3. Adding the live.com account after the gmail.com account (and having two accounts) None of those tasks exhibit the crash presented here. Is this bug still reproducing for anybody else?

Can someone check if this still reproduces on 1.2 & 1.3 on the latest build available?

Crash does not seem to occur in : Gaia 37866768b8abda56d089c8fe96ec5298fc1df696 SourceStamp 8b4d14afc4f6 BuildID 20130922040204 Version 27.0a1 Buri Gaia a13c76f8d3c617ee57c302c103da04ed1a6298d1 SourceStamp b34384409be6 BuildID 20130924004002 Version 26.0a2 Buri

Works for me per comment 40 then. Don't know what fixed this though. Reopen if this reproduces again.

This is passing again in the automation, too.

This looks like it might be a build/compiler issue. I am reopening for now because I still get these crashes with Mozilla-produced b2g-desktop builds in our ActiveSync code-base. When I use the build at http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013-10-27-04-02-00-mozilla-central/b2g-27.0a1.multi.linux-x86_64.tar.bz2 to run the Gaia e-mail app back-end tests, I get crashes. I built my own build for max debug symbols, etc. When I build the same hg rev a80dce1126db locally, I do not get crashes. My build is build with: gcc-4.8.real (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1 and in my mozconfig: ac_add_options --enable-profiling ac_add_options --enable-optimize=-O1 The mozilla build appears to be gcc 4.7.3-0moz1, and the JS engine appears to be built -O3.

Can we consider opening up a followup for this? There's a lot of change of reproducibility from the original bug filed, so it might help to start in a fresh bug instead.

(In reply to Jason Smith [:jsmith] from comment #44) > Can we consider opening up a followup for this? There's a lot of change of > reproducibility from the original bug filed, so it might help to start in a > fresh bug instead. Sure, that sounds appropriate. I'm spinning gcc 4.7.3 builds with default optimization levels now for x86_64 and nexus 4 (mako) now so I can get stacks and platform information and potentially just work-around the problem. Context-wise, the ActiveSync code-base does still use JS 1.7/1.8-style "Iterator()" stuff that might put us on unusual code paths (and maybe some other things that syntactically are ES5-safe but not semantically ES5). I will do the bug churn when that happens which should be later today so those who want to follow-along can do so without even more churn/spam; if you don't see me having done this by late tonight, feel free to re-resolve (or now if you feel strongly).

Okay. I'll close this out for now - I'll let you open a new bug for the issue you saw.

Yeah, my problem was definitely a different problem. DOMWorker shutdown problem. Filed as bug 932143. Unfortunately, even when I work around that, we experience some type of horrible indexedDB File reference segfault.