915223 - crash in 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,

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Florin Strugariu [:Bebe]]

Attachment: logcat of the issue

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

Comment 1

[Florin Strugariu [:Bebe]]

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)

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Do we have a stack?

Comment 3

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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

Comment 4

[Jason Smith [:jsmith]]

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

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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.

Comment 8

[Jason Smith [:jsmith]]

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

Comment 10

[Jason Smith [:jsmith]]

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

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 12

[Jason Smith [:jsmith]]

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

Comment 13

[Jason Smith [:jsmith]]

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.

Comment 14

[Jan de Mooij [:jandem]]

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

Comment 15

[Jason Smith [:jsmith]]

(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.

Comment 16

[Kannan Vijayan [:djvj]]

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.

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 18

[Kannan Vijayan [:djvj]]

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.

Comment 19

[Nicolas B. Pierron [:nbp]]

(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

Comment 20

[Kannan Vijayan [:djvj]]

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?

Comment 21

[Jason Smith [:jsmith]]

(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

Comment 22

[gbennett]

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

Comment 23

[Jason Smith [:jsmith]]

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.

Comment 24

[Jason Smith [:jsmith]]

(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.

Comment 25

[Marcia Knous [:marcia]]

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

Comment 26

[Tony Chung [:tchung]]

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

Comment 27

[Kannan Vijayan [:djvj]]

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?

Comment 28

[Jason Smith [:jsmith]]

(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?

Comment 29

[Kannan Vijayan [:djvj]]

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

Comment 30

[[:fabrice] Fabrice Desré]

(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 :(

Comment 31

[Kannan Vijayan [:djvj]]

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

Comment 32

[[:fabrice] Fabrice Desré]

(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

Comment 33

[Kannan Vijayan [:djvj]]

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.

Comment 34

[Kannan Vijayan [:djvj]]

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

Comment 35

[Darren]

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

Comment 36

[Jason Smith [:jsmith]]

(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.

Comment 37

[Darren]

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.

Comment 38

[Kannan Vijayan [:djvj]]

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?

Comment 39

[Jason Smith [:jsmith]]

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

Comment 40

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 41

[Jason Smith [:jsmith]]

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

Comment 42

[Zac C (:zac)]

This is passing again in the automation, too.

Comment 43

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 44

[Jason Smith [:jsmith]]

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.

Comment 45

[Andrew Sutherland [:asuth] (he/him)]

(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).

Comment 46

[Jason Smith [:jsmith]]

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

Comment 47

[Andrew Sutherland [:asuth] (he/him)]

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.