999434 - crash in js::detail::HashTable<js::Shape* const, js::HashSet<js::Shape*, js::ShapeHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(js::StackShape const&, unsigned int, unsigned int)

Status: RESOLVED WORKSFORME

(Core :: JavaScript: GC, defect)

Description

[Tracy Walker [:tracy]]

This bug was filed from the Socorro interface and is 
report bp-db43d540-bf8b-4315-aada-a96412140418.
=============================================================

This signature has been around for a long time.  However, it's volume began to increase recently, bringing it up to #12 on the Fx30 topcrash list.  It's volume jumped notably with builds from 20140415.  Volume for this signature has also increased on the recent 29 betas.  Either a common uplift of code or an extension is at play here.

Comment 1

[stevend811]

I started having this issue after I installed the HTTPS Everywhere extension (https://www.eff.org/https-everywhere), and all of the crash reports with this signature I've looked at so far have that extension listed as well.

Comment 2

[city_zen]

(In reply to stevend811 from comment #1)
> I started having this issue after I installed the HTTPS Everywhere extension
> (https://www.eff.org/https-everywhere), and all of the crash reports with
> this signature I've looked at so far have that extension listed as well.

I second this. I was having several crashes a day with HTTPS everywhere installed. After uninstalling it, I don't get crashes anymore. I was using the stable (3.x) version of HTTPS everywhere, not the development version (4.x)

Comment 4

[Matt Nordhoff (aka Peng on IRC & forums)]

For what it's worth, and not to start a wild goose chase, I switched to Aurora (32-bit, Linux) at 2014-04-12 06:18 UTC and had an unexplained crash a few hours later. I first started crashing more often at 2014-04-14 05:08. I don't have IDs for either. One or both of these could be a horrible coincidence, or they could help nail down when this issue started. Shrug.

(I run HTTPS Everywhere from git.)

Comment 5

[User Dderss]

Totally random, non-reproducable crash:
https://crash-stats.mozilla.com/report/index/1e2c9406-3641-402f-a571-639472140511

Comment 6

[marco_pal]

The crash signature isn't always the same. I suggest changing the title of this bug. The only thing in common is that is always EXCEPTION_ACCESS_VIOLATION_READ or EXCEPTION_ACCESS_VIOLATION_WRITE. It always happens when some page is loading or switching between tabs, never when idle. I don't know exactly how to reproduce it...
Here I post a set of crashes that I've been having, the first is from 2014-04-16, two days after https everywhere 3.5 was released(now at 3.5.1). Also I tried a few days ago to disable that extension and it didn't happened anymore. 
The first set is from Windows 7 64bit and the last two are from Windows 7 32bit.

https://crash-stats.mozilla.com/report/index/bp-9ac51c25-83ed-4204-99a3-ffb5f2140511
https://crash-stats.mozilla.com/report/index/bp-a05461ba-9fe3-4746-a906-2af402140510
https://crash-stats.mozilla.com/report/index/bp-2b0fbb55-a105-4c7d-a173-22cfd2140502
https://crash-stats.mozilla.com/report/index/bp-a30ffc2e-7a15-4b38-90bc-a364b2140501
https://crash-stats.mozilla.com/report/index/bp-b9120670-8bee-46ee-8748-b258a2140427
https://crash-stats.mozilla.com/report/index/bp-51a03f55-a9b9-4ffb-a25b-2a9142140426
https://crash-stats.mozilla.com/report/index/bp-fa220650-f090-4f50-9e81-6218e2140424
https://crash-stats.mozilla.com/report/index/bp-60cc747d-335d-428a-9299-ec4a12140424
https://crash-stats.mozilla.com/report/index/bp-157d40fc-784f-4a9b-bad8-e09332140423
https://crash-stats.mozilla.com/report/index/bp-bb33e538-92ed-499a-95ff-5837a2140421
https://crash-stats.mozilla.com/report/index/bp-549953e6-f598-453f-b2c7-360ed2140419
https://crash-stats.mozilla.com/report/index/bp-c725fa9e-4ac0-43a1-9d1c-c318c2140418
https://crash-stats.mozilla.com/report/index/bp-ac73d0b1-874b-4ad8-aa1c-4dafc2140417
https://crash-stats.mozilla.com/report/index/bp-58720b81-ca3f-4c7f-bf7c-97d602140417
https://crash-stats.mozilla.com/report/index/bp-d123757b-7382-4bd2-b83e-eb02b2140416
https://crash-stats.mozilla.com/report/index/bp-f0c0da89-895b-4c4c-9090-8aa982140416



https://crash-stats.mozilla.com/report/index/6d05241f-7247-45dd-baba-4328b2140429
https://crash-stats.mozilla.com/report/index/51b15525-e857-4ca4-b1ac-97f002140502

Posted also on https://trac.torproject.org/projects/tor/ticket/11700

Comment 7

[User Dderss]

Another case:
https://crash-stats.mozilla.com/report/index/ad948aaf-6447-44d4-957e-7ece22140514

Comment 8

[piotrszegda]

Next crash: https://crash-stats.mozilla.com/report/index/66029195-2080-4760-a325-6f2dc2140529

I clicked right mouse button on website.

Comment 9

[david gang]

I have also a crash
https://crash-stats.mozilla.com/report/index/740a2a90-3528-4097-ab00-3a2ee2140611

Comment 10

[Liu Xing]

https://crash-stats.mozilla.com/report/index/43701b24-e0e6-4fe0-a597-a99232140613

Comment 12

[yan]

Hey, I'm chiming in as the HTTPS Everywhere maintainer. It appears that stable releases (3.x) above version 3.4.5 consistently show this crash. It's unclear whether 4.0development.17 (the latest development release also has this issue) - I've been using it on 64 bit debian without issues.

I'll attach a diff between 3.4.5 to 3.5 (minus ruleset .xml files) for folks to look at.

Comment 13

[yan]

FWIW, this is also being discussed at https://github.com/EFForg/https-everywhere/issues/262 and https://trac.torproject.org/projects/tor/ticket/11700.

Comment 14

[yan]

Attachment: https everywhere 3.4.5 to 2.5 diff

Comment 15

[yan]

(In reply to yan from comment #13)
> FWIW, this is also being discussed at
> https://github.com/EFForg/https-everywhere/issues/262 and
> https://trac.torproject.org/projects/tor/ticket/11700.

One thought: perhaps this is related to HTTPS Everywhere recently transitioning from an in-memory XML data structure for its URL rewrite rules to a sqlite db. A test for this would be to see if the crashes happen on 4.0dev.16 but not 4.0dev.15. (Changelogs: https://www.eff.org/files/Changelog.txt)

Comment 16

[yan]

(In reply to yan from comment #15)
> One thought: perhaps this is related to HTTPS Everywhere recently
> transitioning from an in-memory XML data structure for its URL rewrite rules
> to a sqlite db. A test for this would be to see if the crashes happen on
> 4.0dev.16 but not 4.0dev.15. (Changelogs:
> https://www.eff.org/files/Changelog.txt)

Oops, I meant "4.0dev.15 but not 4.0dev.14".

Comment 17

[yan]

Multiple people have now reported that turning off SSL Observatory seems to fix the crash.

Comment 18

[Liu Xing]

(In reply to yan from comment #17)
> Multiple people have now reported that turning off SSL Observatory seems to
> fix the crash.

OK. Thanks.
I will try it now.

Comment 19

[Tobias B. Besemer [:BesTo] (QA)]

Guess this bug is now a dup of bug 645881 ... but I let anyway both open...

Comment 20

[Karla Merza [Away. Please needinfo? Brindusa Tot[:brindusat] ]]

From the crash signatures from the bug (js::detail::HashTable<T>::lookup) and comment section (AppendRequestsToArray and poolDestroy), the current affected versions are:
- Aurora: 46
- Beta: 44.0b1, 45.0b1, 45.0b2, 44.0b7, 44.0b9, 44.0b99

From the crash report FindFlowForContent, the current affected versions are:
- Nightly: 47
- Aurora: 46
- Beta: 44.0b4, 44.0b8, 44.0b9, 44.0b99, 45.0b1, 45.0b2

Comment 21

[Wayne Mery (:wsmwk)]

Only 3 crash in past month all android.