344214 - Multiple crashes since landing of JS 1.7 on 1.8 branch

Status: RESOLVED DUPLICATE of bug 335018

(Core :: JavaScript Engine, defect)

Description

[Reed Loden [:reed]]

According to talkback-public, there has been a huge increase in crashes since the landing of JS 1.7 on the 1.8 branch.

Here are some of my personal talkback IDs that are JS related (not sure if they are the same bug, though):
TB20728976E (2006070805)
TB20772265K (2006070904)
TB20806918X (2006071003)
TB20811944W (2006071003)
TB20815013W (2006071003)

My current build id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 BonEcho/2.0b1 ID:2006071003

Comment 1

[Bob Clary [:bc] (inactive)]

I am not sure how we can separate out the digg effect of many more people downloading the beta1 rc1 from the increase in crashes.

Comment 2

[Reed Loden [:reed]]

(In reply to comment #1)
> I am not sure how we can separate out the digg effect of many more people
> downloading the beta1 rc1 from the increase in crashes.

Well, I've been using 1.8 branch nightlies for a while, and the last couple of days has shown a large increase in crashes during my personal use (as shown in TB IDs above).

Comment 3

[timeless]

well, three of them are:
  
Incident ID: 20806918
Stack Signature	ntdll.dll + 0x106c3 (0x7c9106c3) d1e5cbbb
Product ID	Firefox2
Build ID	2006071003
Trigger Time	2006-07-10 18:55:58.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	ntdll.dll + (000106c3)
URL visited	
User Comments	
Since Last Crash	39214 sec
Total Uptime	39214 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
ntdll!RtlAllocateHeap+0xef (0x7c9106c3)
msvcrt!calloc+0x118 (0x77c2c1db)
CreateScopeTable  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsscope.c, line 122]
js_SetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 3417]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 5393]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1368]
nsXPCWrappedJSClass::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1415]
nsXPCWrappedJS::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsObserverService::NotifyObservers  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/ds/nsObserverService.cpp, line 235]
XPTC_InvokeByIndex  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2160]
XPC_WN_CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1450]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1349]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 4085]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1368]
nsXPCWrappedJSClass::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1415]
nsXPCWrappedJS::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsWebBrowserPersist::OnStopRequest  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp, line 775]
nsStreamListenerTee::OnStopRequest  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsStreamListenerTee.cpp, line 65]
nsInputStreamPump::OnStateStop  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 564]

Comment 4

[Reed Loden [:reed]]

Another one of mine: TB20823641M (2006071003)

Comment 5

[chris hofmann]

reed's recent talkback history looks something like:

MozillaOrgFirefox2Win322006071003 
20823641 AutoMarkingPtr::`vftable' 09f72cfa 2006-07-11 03:33:38.0

20815013 ntdll.dll + 0x106c3 (0x7c9106c3) d1e5cbbb 	2006-07-11 01:32:53.0

20811944 ntdll.dll + 0x106c3 (0x7c9106c3) d1e5cbbb 	2006-07-10 22:58:26.0

20806918 ntdll.dll + 0x106c3 (0x7c9106c3) d1e5cbbb 	2006-07-10 18:55:58.0

20772265 JS_GetFunctionName 2303b2f3 	2006-07-09 23:16:14.0

MozillaOrgFirefox2Win322006070805 
20728976 SinkContext::IsCurrentContainer 3593a004 	2006-07-08 12:38:27.0

Comment 6

[Jay Patel [:jay]]

Digg effect or not, there was an obvious spike in crashes on and after 7/7, so this is worth checking out.  That spike might be a result of more users testing with the latest 1.8.1 builds, but chances are a few of them are regressions from the JS landing.

If you look at http://talkback-public.mozilla.org/reports/firefox/FF2x/smart-analysis.all under the ntdll.dll stack signature, there are a number of JS related crashes that should be investigated.

If Blake or Brendan can take a look and figure out if a few of them are new, we can get bugs logged for individual crashes and try to tackle one at a time.

Comment 7

[Brendan Eich [:brendan]]

It's hard to be sure, but it looks like these signatures (at any crash count above 1) are novel to the 1.8 branch since js1.7 landed, and *not* on the trunk. Jay, do you agree?

Reed, can you list all the extensions you're using? Thanks.

/be

Comment 8

[Reed Loden [:reed]]

(In reply to comment #7)
> Reed, can you list all the extensions you're using? Thanks.

Go go handy-dandy Nightly Tester Tools!

Adblock Filterset.G Updater 0.3.0.4
Adblock Plus 0.7.1 [DISABLED]
DOM Inspector 1.8.1b1
Forecastfox 0.9.2
Google Toolbar for Firefox 2.0.20060606W [DISABLED]
IE Tab 1.0.9.5
Live HTTP Headers 0.12 [DISABLED]
Nightly Tester Tools 1.1
Talkback 2.0b1
Update Channel Selector 1.0.1

Comment 9

[Brendan Eich [:brendan]]

(In reply to comment #8)
> (In reply to comment #7)
> > Reed, can you list all the extensions you're using? Thanks.
> 
> Go go handy-dandy Nightly Tester Tools!
> 
> Adblock Filterset.G Updater 0.3.0.4
> Adblock Plus 0.7.1 [DISABLED]
> DOM Inspector 1.8.1b1
> Forecastfox 0.9.2
> Google Toolbar for Firefox 2.0.20060606W [DISABLED]
> IE Tab 1.0.9.5
> Live HTTP Headers 0.12 [DISABLED]
> Nightly Tester Tools 1.1
> Talkback 2.0b1
> Update Channel Selector 1.0.1

Wow.  OK, if you are willing: disable half of these and run for enough time to see whether you crash at roughly the same rate.  If you do, disable half of the remaining, etc.  If you don't, enable half of those you disabled -- IOW binary search for the "bad" extension.

This would be extremely helpful, if there actually *is* an extension tickling a bug that we landed with js1.7.  Thanks,

/be

Comment 10

[Jay Patel [:jay]]

Brendan:  From looking at the data for FirefoxTrunk, it does appear that these crashes are unique to the 1.8 branch.   No apparent spike in Trunk crashes...and not too many stacks similar to the ones in this bug.  

I wonder if bc can put together some basic js tests around the js1.7 landing and run them on both Trunk and 1.8 builds?

Comment 11

[Brendan Eich [:brendan]]

Jay: there wouldn't be a trunk spike because js1.7 has been landing in pieces on the trunk for months.  As of the 1.8 landing on 7/6, js/src/*.[ch] and related files in js/src were identical between branch and trunk, and only a handful of followup fixes have gone into the trunk (one of which went into the branch for beta 1).

So it seems something is different in source outside of the JS engine's sources on the branch; or something is triggering this "only" for certain branch users such as Reed due to their extension mixes; or both.

/be

Comment 12

[Bob Clary [:bc] (inactive)]

damn, midair again. 

No need to cc me on js bugs as I watch the generic addresses and everyone who touches js. 

I did test all three branches on all platforms and sent my testing results out this weekend. Unfortunately, as we have seen with some regressions I didn't catch during my testing the js test library coverage isn't 100%.

<quote>
I found the following issues during the latest round of testing. I don't know if they are significant enough to warrant changes in the schedule.

<https://bugzilla.mozilla.org/show_bug.cgi?id=336409> 1.8.0.5/1.8.1/1.9
<https://bugzilla.mozilla.org/show_bug.cgi?id=336410> 1.8.0.5/1.8.1/1.9
<https://bugzilla.mozilla.org/show_bug.cgi?id=341956> 1.8.1
<https://bugzilla.mozilla.org/show_bug.cgi?id=342793> 1.8.1/1.9 *
<https://bugzilla.mozilla.org/show_bug.cgi?id=342960> 1.8.1
<https://bugzilla.mozilla.org/show_bug.cgi?id=343295> 1.8.1/1.9
<https://bugzilla.mozilla.org/show_bug.cgi?id=343455> 1.8.1/1.9 *
<https://bugzilla.mozilla.org/show_bug.cgi?id=343984> 1.8.1

* need to test with updated patch from
<https://bugzilla.mozilla.org/show_bug.cgi?id=341821>
</quote>

I didn't see any of the stacks that Reed is reporting during my testing.

I dogfood ff2/bonecho and haven't seen an increase in crashes. I do have the standard (up to date) plugins installed but very few extensions and certainly not the list that Reed has installed.

Reed, it would help if you gave us steps on how to reproduce the crashes including urls etc. I looked at the internal talkback reports for your crashes and didn't see anything that would help reproduce these.

Comment 13

[Reed Loden [:reed]]

(In reply to comment #9)
> Wow.  OK, if you are willing: disable half of these and run for enough time to
> see whether you crash at roughly the same rate.  If you do, disable half of the
> remaining, etc.  If you don't, enable half of those you disabled -- IOW binary
> search for the "bad" extension.

ok, half disabled.


(In reply to comment #12)
> Reed, it would help if you gave us steps on how to reproduce the crashes
> including urls etc. I looked at the internal talkback reports for your crashes
> and didn't see anything that would help reproduce these.

Strangely enough, it seems to crash when I'm not on my laptop at all. I usually go off to do something, come back, and find that it has crashed while I was gone.

Comment 14

[Brendan Eich [:brendan]]

(In reply to comment #12)
> I found the following issues during the latest round of testing. I don't know
> if they are significant enough to warrant changes in the schedule.
> 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=336409> 1.8.0.5/1.8.1/1.9
> <https://bugzilla.mozilla.org/show_bug.cgi?id=336410> 1.8.0.5/1.8.1/1.9

These are fixed and bug 344137 looks like the one tracking the apparent Windows js shell and all-platforms browser crash you are still seeing with 1.8.1 but not trunk.  That's obviously odd, since the original fixes cured the symptoms on the trunk.

> <https://bugzilla.mozilla.org/show_bug.cgi?id=341956> 1.8.1

This is fixed on trunk but mysteriously not on 1.8 branch after js1.7 landed, even though all the js*.[ch] etc. sources landed.  Need more info in that bug.

> <https://bugzilla.mozilla.org/show_bug.cgi?id=342793> 1.8.1/1.9 *
> <https://bugzilla.mozilla.org/show_bug.cgi?id=343455> 1.8.1/1.9 *

These need a followup patch as you noted.  That's yet to be written, lack of it should not hold up beta.

> <https://bugzilla.mozilla.org/show_bug.cgi?id=342960> 1.8.1

Commented in this bug just now.

> <https://bugzilla.mozilla.org/show_bug.cgi?id=343295> 1.8.1/1.9

This bug needs an owner.

> <https://bugzilla.mozilla.org/show_bug.cgi?id=343984> 1.8.1

See bug 140852, apparently you are using a broken MS compiler?  Does -Op or whatever the latest name for that option is (if it exists) help?  Never mind, I'll talk to you in that bug. ;-)

None of these are this bug.  Some need owners.  All should be linked to a tracking bug -- can you make one and link it to the js1.7 bug, so we don't lose track?  Thanks for summarizing.

/be

Comment 15

[IU]

Ok.  Here's a method for reproducing this bug.

First, the reasoning behind my method: My suspicion, like many others, is that the problem is in fact with the js1.7 engine and not any extension in particular.  Second, since the crashes do also occur when the browser is idle (i.e. no pages loading and no user interaction), it is also my suspicion that, where the crash is triggered by an extension, such extension must be one that regularly performs operation in the background (e.g. Session Manager, 1-Click Weather, ForecastFox, etc.); otherwise, crashes triggered by generally "static" extensions (e.g. Adblock Plus, Nightly Tester Tools, Flashblock, FlashGot, etc.) would only occur when invoked as a result of user interaction or page loading.  Thus, such factors need to be taken into consideration both when selecting an extension to test with and when observing a crash where a particular extension is presumed to be the "culprit."

1. Install Bon Echo Official Win32 20060711 [Branch] build (used .exe build) with Talkback
2. Create a new profile and launch Bon Echo
3. Install Session Manager 0.4.2.2+ (note: this is the "Testing Version" located at http://forums.mozillazine.org/viewtopic.php?t=406098 )
4. Leave all other browser settings (with the exception of the "default browser" setting) at their defaults.
5. Restart the browser
6. Open three additional tabs (in addition to the default page) and load them with content.
7. Browse till the browser goes south and triggers Talkback

My talkback for this particular crash was: TB20847174Y

Note: My reason for choosing Session Manager was precisely because is does frequently perform background activity, and thus I highly anticipated it would trip up something in the JavaScript interpreter.  If you are using an extension which (practically) never performs an operation while you browse (i.e. is dormant until you specifically, in the rare occasion, invoke it) then there is a very high probability you will not observe a crash.

A tad verbose, but I hope this helps, as the general public is going to roast y'all once they encounter this instability in the beta. :-)

Comment 16

[Doug Halamay]

I've been a regular 1.8 branch nightly user, and since 7/7, I've also been seeing a noticeable increase in crashes.  As reported, it seems to happen when I leave the browser idle for awhile and then come back to it.  My extensions:

Adblock Plus 0.7.1
Console² 0.3.5
DOM Inspector 1.8.1b1
FireFTP 0.94.2
Forecastfox 0.9.2
Launchy 4.2.0
Nightly Tester Tools 1.1
Tab Mix Plus 0.3.0.60601
Tab Preview 0.3
text/plain 1.1.7
User Agent Switcher 0.6.8
View Source Choice 0.3

Doing a quick compare to Reed's list, it looks like we have these in common:
Adblock Plus 0.7.1
Forecastfox 0.9.2
Nightly Tester Tools 1.1

Judging from the fact that it seems to happen during idle-time and not during actual page loading, interaction, etc., I'd hazard a guess and say that Forecastfox is causing the problem, since it does automated periodic refreshes of the weather data.  I'll try disabling Forecastfox for a little bit and see what happens.

Comment 17

[Reed Loden [:reed]]

(In reply to comment #16)
> Doing a quick compare to Reed's list, it looks like we have these in common:
> Adblock Plus 0.7.1
> Forecastfox 0.9.2
> Nightly Tester Tools 1.1

Adblock Plus is disabled on my system, so that leaves only Forecastfox and Nightly Tester Tools.

> Judging from the fact that it seems to happen during idle-time and not during
> actual page loading, interaction, etc., I'd hazard a guess and say that
> Forecastfox is causing the problem, since it does automated periodic refreshes
> of the weather data.  I'll try disabling Forecastfox for a little bit and see
> what happens.

I agree. Forecastfox sounds like a likely culprit for some of these issues. It was part of the half I disabled earlier, and I haven't received any crashes since then (only several hours though... I'll see how tomorrow goes).

Comment 18

[timeless]

timeless@boffo:/tmp/ff00$ wget http://releases.mozilla.org/pub/mozilla.org/extensions/forecastfox/forecastfox-0.9.2-fx+fl+mz+ns+zm.xpi
timeless@boffo:/tmp/ff00$ unzip forecastfox-0.9.2-fx+fl+mz+ns+zm.xpi
timeless@boffo:/tmp/ff00$ cd chrome/
timeless@boffo:/tmp/ff00$ unzip forecastfox.jar
timeless@boffo:/tmp/ff00$ cd ..
timeless@boffo:/tmp/ff00$ grep -r -l nsIWebBrowserPersist .
./chrome/forecastfox.jar
./chrome/content/forecastfox/icons.js
./components/nsForecastfox.js

conclusion: forecastfox uses webbrowserpersist. i'd rather not personally check each of the other named extensions, but if someone else has time to use it to rule them out, that'd be appreciated.

Comment 19

[IU]

How can Forecastfox be the culprit when the crash also occurs with Session Manager and a host of other extensions?  It's like nobody read my earlier post.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #19)
> How can Forecastfox be the culprit when the crash also occurs with Session
> Manager and a host of other extensions?  It's like nobody read my earlier post.

It's possible for there to be multiple "culprits", just as it's possible that there are multiple bugs that lead to crashes.

Comment 21

[Simon Bünzli]

This definitively not only happens with ForecastFox.

TB20892978W
TB20893036H

And should this be the same issue: Session Manager doesn't user nsIWebBrowserPersist (directly) at all.

Comment 22

[Martijn Wargers (dead)]

I opened up a Firefox2 beta build with the forecastfox0.9.2 extension installed.
Firts I get this assertion:
###!!! ASSERTION: Null found in classinfo interface list: 'Error', file c:/mozil
la181/mozilla/js/src/xpconnect/src/xpcwrappednativeinfo.cpp, line 636
Break: at file c:/mozilla181/mozilla/js/src/xpconnect/src/xpcwrappednativeinfo.c
pp, line 636
http://www.wargers.org/mozilla/forecastfox/classinfo_null.txt
which doesn't sound like a good thing.
Then I get a whole bunch of thread safety assertions (zipped them up here):
http://www.wargers.org/mozilla/forecastfox/alles.zip
Boris said something about those at bug 336915 comment 11.

Note, I can make Firefox crash quite easily (within 10 times trying, in a debug build even easier), by right-clicking and doing "Reload Wheather Data" and then quickly again right-clicking on the forecastfox toolbar.
Talkback ID: TB20894759Y - ntdll.dll + 0x11f6e (0x7c911f6e)
Talkback ID: TB20866225M - nsXBLBinding::InstallAnonymousContent

Comment 23

[Martijn Wargers (dead)]

And I get those same threadsafe assertions after I've installed Session Manager:
https://addons.mozilla.org/firefox/2324/
Although not as a continuing flood of assertions, like forecastfox, but still quite a lot, especially when browsing a bit.
I'm not sure how those extensions should be fixed.

Comment 24

[Simon Bünzli]

Attachment: minimal testcase (Session Manager crash)

This is a minimal testcase for what causes Session Manager to trigger a crash. Note that it doesn't always take the same amount of threads until the crash (occasionally even 1000 iterations aren't enough).

To get Talkback reports, simply copy this code into your userChrome.js [1] and open a new window (of course any other way of running it as privileged code should do as well).

[1] http://forums.mozillazine.org/viewtopic.php?t=397735

Comment 25

[timeless]

the null classinfo thing is an assertion i was forced to add, it's relatively harmless and mostly means that some class was not written aware that some interface doesn't exist for the application that's actually hosting it. i.e. someone should go figure out which interface in the list doesn't exist and figure out what to actually do.

the threadsafe stuff usually means that the objects are using dom windows to host js objects that run outside of windows and can easily outlive them. this is a very big problem.

as to the isn't the problem not blah nonsense. i'm sorry, i refuse to fix more than one crash per bug. if it turns out that there's more than one crash floating around, then reed will gladly fork off whichever other crashes we discover into other bugs. that said, you shouldn't file extra bugs until you can find extra problems, and "crashing somewhere, I don't know where, I don't care" is not an extra problem, so this bug will work until someone can actually show a distinct other problem.

Comment 26

[Martijn Wargers (dead)]

Attachment: testcase

Thanks for the testcase, Simon! This is the testcase from Simon with enhanced privileges. You can test it locally on the computer.
This doesn't crash with a 2006-07-06 branch build, but crashes with a 2006-07-07 branch build.
This is indeed the time when JS1.7 was landed on the branch.

Comment 27

[Nikola Kocić]

Testcase WFM (Firefox doesn't crash)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060714 BonEcho/2.0b1 - Build ID: 2006071403

Comment 28

[Felix Miata]

All available post-2006070509 OS/2 1.8 SM nightlies crash on the 229393 testcase -> ALL

Linux 2006071700 SM 1.8 branch nightly does not crash on the 229393 testcase.

Comment 29

[Brendan Eich [:brendan]]

mrbkap suggested that this might be a dup of bug 335018.  He's got a point -- Martijn, can you test accordingly?  Feng has a patch in that bug.

/be

Comment 30

[Martijn Wargers (dead)]

Yes, after I've added Feng's patch from bug 335018 in my 1.8.1 build, I don't crash anymore.

Comment 31

[Brendan Eich [:brendan]]

*** This bug has been marked as a duplicate of 335018 ***

Comment 32

[Feng Qian (Google)]

(In reply to comment #26)
> Created an attachment (id=229393) [edit]
> testcase
> 
> Thanks for the testcase, Simon! This is the testcase from Simon with enhanced
> privileges. You can test it locally on the computer.
> This doesn't crash with a 2006-07-06 branch build, but crashes with a
> 2006-07-07 branch build.
> This is indeed the time when JS1.7 was landed on the branch.

How to run the testcase? I downloaded it on my local computer, and open the page, I got the following error in JS console:

Error: Components.classes['@mozilla.org/thread;1'] has no properties.

> 

Comment 33

[Martijn Wargers (dead)]

(In reply to comment #32)
> Error: Components.classes['@mozilla.org/thread;1'] has no properties.

It doesn't work on trunk (I think because of Darin's threadmanager patch), you need to test on the 1.8.1 branch.

Comment 34

[Martijn Wargers (dead)]

I'm reopening this bug, the latest patch in bug 335018 doesn't fix this crash.

Comment 35

[Feng Qian (Google)]

(In reply to comment #34)
> I'm reopening this bug, the latest patch in bug 335018 doesn't fix this crash.

Was the crash on Windows? I verified it on Linux.

Comment 36

[Martijn Wargers (dead)]

(In reply to comment #35)
> Was the crash on Windows? I verified it on Linux.

Yes, the crash is on windows.

Comment 37

[Martijn Wargers (dead)]

I just rebuild completely with the second patch of bug 335018 (previously I just rebuilt js/) and now I don't crash anymore with the testcase.
So I guess this bug will be fixed when bug 335018 gets fixed.
Sorry for the confusion :/

Comment 38

[Martijn Wargers (dead)]

Marking this a duplicate of bug 335018, again sorry for the confusion.

*** This bug has been marked as a duplicate of 335018 ***