453708 - TM: crash opening a link to google maps [@ js_MonitorRecording(JSContext*)]

Status: VERIFIED WORKSFORME

(Core :: JavaScript Engine, defect, P1)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080903034741 Minefield/3.1b1pre ID:20080903034741
JIT enabled

repro:
click on the next link

result:
crash

w/i JIT no crash

bp-7a8c53fa-7ac7-11dd-8012-001a4bd43ed6
bp-68f8a219-7ac9-11dd-a18d-001cc45a2ce4

Comment 1

[Andreas Gal :gal]

Would you mind re-testing this with the current nightly?

be: We seem to be hitting MonitorRecording while not recording, so recorder is NULL and we check for deep abort on it, which causes the exception.

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

While I can't read the Dutch language, I don't see anything on a US map that
say's "Next" ..  I was all over the map, and I can't get it to crash here.

I'm using a later build than Peter,

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre)
Gecko/20080904044504 Minefield/3.1b1pre Firefox/3.0 ID:20080904044504

Comment 3

[Andreas Gal :gal]

I tested the link provided with m-c nightly on Windows and tm tip and I can't reproduce it. Closing the bug. Please re-open if it still crashes for you.

Comment 4

[Tobias Fischer]

Reopen - Can reproduce the crash using:
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080905002005 Mnenhy/0.7.5.20005 SeaMonkey/2.0a1pre

with JIT content enabled. Add several Breakpad-IDs:

bp-8185f33a-7b2f-11dd-a361-001cc4e2bf68
bp-5b45d954-7b2f-11dd-9abd-001321b13766
bp-311e00a3-7b2f-11dd-b8fa-001cc4e2bf68
bp-0da12dfd-7b2f-11dd-b0d0-001cc4e2bf68
bp-aa115214-7b2e-11dd-8552-001cc45a2ce4
bp-3a7be842-7b2e-11dd-b9d8-001a4bd43ed6
bp-e7c04878-7b2d-11dd-8486-001cc45a2c28
bp-4cc8fc66-7b2d-11dd-802b-0013211cbf8a

I got two different crash signatures, [@ jsd_FunctionCallHook ] and 
[@ ntdll.dll@0x100b ]

I cant reproduce this crash with SeaMonkey on MacOS X 10.5.x.

Note, that it seems to be a little tricky to reproduce the crash. First I run into the crash, I do this (Steps to reproduce):

1. open http://maps.google.de/maps?hl=en&tab=wl (maps.google.com should crash too)

2. Enter Address in Google-Maps Searchfield, Return,

3. Close the Result-Location-Bubble, and zoom some steps into the map, than change to satellite view and zoom in again several steps.

Result:
This crashes SeaMonkey reproduceable for me. 


Other way to crash SeaMonkey:

1. Open http://maps.google.de/maps?hl=en&tab=wl
2. Zoom into the map several steps (need almost three, better six steps)
3. Drag the Map with Mouse fast several times

Result:
SeaMonkey crashes. 


It might to be easier to trigger the crash in satellite-view than map-view, but zooming in some steps seems to be necessary anyway.

Comment 5

[(not currently active) Ted Mielczarek]

I can't reproduce this using any of the steps given on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080904035000 Minefield/3.1b1pre.

Comment 6

[Tobias Fischer]

(In reply to comment #5)
> I can't reproduce this using any of the steps given on Mozilla/5.0 (Windows; U;
> Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080904035000 Minefield/3.1b1pre.

Indeed. Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080905031652 Minefield/3.1b1pre 

I was not able to crash FF with any of the given steps. 
But SeaMonkey 20080905002005 will crash reproduceable: 
bp-5607e428-7b45-11dd-b34e-001cc4e2bf68

Hmm. I will give SeaMonkey another try using an fresh and clean Profile.

Comment 7

[Tobias Fischer]

There seems to be something wrong with our bloody SeaMonkey today. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.1b1pre) Gecko/20080905002005 

with an fresh and clean Profile, without any extra installed Add-Ons, only customized by setting JIT for content "true" crashes:

bp-ce0ff3c2-7b46-11dd-9dcc-001cc45a2ce4
bp-a60dbb85-7b46-11dd-91f0-001a4bd43e5c
bp-5cb72670-7b46-11dd-b597-0013211cbf8a

Is there any significant difference between FF and SM?

Comment 8

[Andreas Gal :gal]

We seem to be crashing in jsd_*. Does SeaMonkey use the debugger interface for something?

Comment 9

[Tobias Fischer]

(In reply to comment #8)
> We seem to be crashing in jsd_*. Does SeaMonkey use the debugger interface for
> something?

Far out of my knowledge. But searching the jsd3250.dll in comm-central gives 8 results, in mozilla-central only 5. 
http://mxr.mozilla.org/comm-central/search?find=%2F&string=jsd3250
http://mxr.mozilla.org/mozilla-central/search?string=jsd3250

SeaMonkey ships the jsd3250.dll in the programms ..\seamonkey\components Folder, Firefox does not ships this dll.

Comment 10

[(not currently active) Ted Mielczarek]

Tobias: Firefox builds the jsd component as part of libxul, SeaMonkey builds a shared build and ships it as a separate DLL. That's all. Are you using Firebug or Venkman or something?

Comment 11

[Tobias Fischer]

No, I am not using Firebug or Venkman. And sorry, but I think I can't help here anymore, because I just know nothing about JS and debugging. :(

Comment 12

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080905031348 Minefield/3.1b1pre ID:20080905031348

I can't reproduce this anymore with my current build

and I can't repro it with the steps in comment #4 anymore

Comment 13

[timeless]

jsd hooks using a certain notification, it's typically registered when you first use venkman (e.g. years ago) and if you don't explicitly unregister it, it's easy to have it still there even if venkman isn't.

you can try deleting compreg before launching firefox....

Comment 14

[(not currently active) Ted Mielczarek]

We're showing a few crashes here in Socorro:
http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&version=Firefox%3A3.1b1pre&signature=js_MonitorRecording(JSContext*)

Some of the comments mention crashing at Google Books.

Comment 15

[Tobias Fischer]

(In reply to comment #13)
> jsd hooks using a certain notification, it's typically registered when you
> first use venkman (e.g. years ago) and if you don't explicitly unregister it,
> it's easy to have it still there even if venkman isn't.

At moment I use a new System I have assembled end of July. I only copied the user.js and the MBox-Files into the new created Profile on the new System. And sure I have not run Venkman nor Firebug on the new System. 
> 
> you can try deleting compreg before launching firefox....

Have tried this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909002343 Mnenhy/0.7.5.20005 SeaMonkey/2.0a1pre, 
but crashes again on maps.google.de:
bp-daee6b35-7f13-11dd-b7fd-001a4bd43ef6

Also 2008-09-09 SeaMonkey-Nightly-Builds crash reproduceable running the SunSpider test while running 3d-raytrace test on Win and Mac. The Stacks are looking not too different, pointing to something in jsd, so I add them here:

Windows [@ jsd_Lock ]:
bp-dae8a568-7f0f-11dd-9f81-001cc4e2bf68
bp-b3da103a-7f0f-11dd-a8c4-0013211cbf8a

Mac [@ libjsd.dylib@0x25d1 ]:
bp-1b649eee-7e90-11dd-8132-001a4bd43ef6
bp-6cd0982b-7e8c-11dd-99ef-001a4bd43ed6
bp-9fd93b70-7e8c-11dd-8538-001cc4e2bf68
bp-510d8ede-7e90-11dd-b70b-0013211cbf8a

Comment 16

[Tobias Fischer]

Who ho, Mnyromyr advice me to really disable the JavaScript-Debugger 0.9.87.4 comes with the SeaMonkey-Trunk-Zip-Builds and is enabled by default. With JSD disabled the named crashes are gone. So this might be closed now, if the crashes were caused by the jsd, and not by the JavaScript-Engine. 

Perhaps SM should disable the JSD by default before shipping the Alpha-Release to avoid irritating crashes, will file a new Bug for that.

Comment 17

[Tobias Fischer]

Filed Bug 454561, disable JSD by default in SeaMonkey (almost for the Release-Builds).

Comment 18

[(mostly gone) XtC4UaLL [:xtc4uall]]

some crashes with Minefield/3.1b1pre ID:20080911105329 [@ js_MonitorRecording(TraceRecorder*)] with my  "working" profile (JIT content enabled only) including several extensions (no Firebug, no Venkman, but DOMi):

bp-867419c2-8060-11dd-84fd-001a4bd43e5c
bp-f964a7e3-8060-11dd-9801-001321b13766
bp-3002367d-8061-11dd-b8a6-001cc4e2bf68

trying to open a google books site: http://tinyurl.com/4oh28a
cannot repro with a clean profile.

Comment 19

[Andreas Gal :gal]

I can't reproduce this with a current tracemonkey tinderbox build. I will close this bug since google maps is working. If someone wants to do some testing with Firebug and JIT interaction and file a more concrete bug on that, that would be very welcome.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We shouldn't close bugs when they still occur on official nightly builds. Reopen this one until the merge is done.

This one is still crashing:
bp-3ea0f62b-8d9b-11dd-88da-001a4bd43ef6

Comment 21

[Jean-Marc Desperrier]

I just got the following stack with the latest nightly  (js_MonitorRecording, like in the title), but not on Google, and I couldn't repro easily. I also didn't get a breakpad prompt, the stacks comes from VS 2005.

Does it sound like the same bug, or something else ?

 	js3250.dll!js_MonitorRecording(TraceRecorder * tr=0x00000010)  Line 2706	C++
	js3250.dll!JS_DHashTableOperate(JSDHashTable * table=0x00000000, const void * key=0x00000000, JSDHashOperator op=JS_DHASH_ADD)  Line 599 + 0x46 bytes	C++
 	xul.dll!jsd_FunctionCallHook(JSContext * cx=0x5cc24165, JSStackFrame * fp=0x0012fa50, int before=0x0012faac, int * ok=0x002f414b, void * closure=0x0072c600)  Line 287 + 0x1c bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x0072c600, unsigned int argc=0x00000001, long * vp=0x0135d020, unsigned int flags=0x00000000)  + 0x5b0aa bytes	C++
 	js3250.dll!JS_CallFunctionValue(JSContext * cx=0x0072c600, JSObject * obj=0x0135ad40, long fval=0x045066a0, unsigned int argc=0x00000001, long * argv=0x08df87d0, long * rval=0x0012fb24)  Line 5133 + 0xe1 bytes	C++
 	xul.dll!nsJSContext::CallEventHandler(nsISupports * aTarget=0x00968190, void * aScope=0x0135ad40, void * aHandler=0x045066a0, nsIArray * aargv=0x098ece24, nsIVariant * * arv=0x0012fbac)  Line 2000 + 0x22 bytes	C++
 	xul.dll!nsGlobalWindow::RunTimeout(nsTimeout * aTimeout=0x08efe3c0)  Line 7715	C++
 	xul.dll!nsGlobalWindow::TimerCallback(nsITimer * aTimer=0x098e5580, void * aClosure=0x08efe3c0)  Line 8048	C++
 	xul.dll!nsTimerImpl::Fire()  Line 420 + 0x7 bytes	C++
 	xul.dll!nsTimerEvent::Run()  Line 514	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x0012fca8)  Line 511	C++
 	xul.dll!nsBaseAppShell::Run()  Line 169	C++
 	xul.dll!nsAppStartup::Run()  Line 183	C++
 	xul.dll!XRE_main(int argc=, char * * argv=, const nsXREAppData * aAppData=)  Line 3269	C++
 	mozcrt19.dll!arena_dalloc_small(arena_s * arena=0x00000000, arena_chunk_s * chunk=0x00700000, void * ptr=0x78138e58, arena_chunk_map_s * mapelm=0x00000000)  Line 4268	C
 	mozcrt19.dll!arena_dalloc_small(arena_s * arena=0x00000000, arena_chunk_s * chunk=0x0071e228, void * ptr=0x00000000, arena_chunk_map_s * mapelm=0x00000000)  Line 4268	C
 	xul.dll!nsLocalFile::Release()  Line 754 + 0x13 bytes	C++
 	xul.dll!nsCOMPtr_base::~nsCOMPtr_base()  Line 82	C++
 	xul.dll!nsLocalFile::Release()  Line 754 + 0x13 bytes	C++
 	xul.dll!nsCOMPtr_base::~nsCOMPtr_base()  Line 82	C++
 	xul.dll!XRE_CreateAppData(nsILocalFile * aINIFile=0x00000001, nsXREAppData * * aAppData=0x0071b098)  Line 140 + 0x8 bytes	C++
 	firefox.exe!wmain(int argc=0x00000001, wchar_t * * argv=0x00719800)  Line 87 + 0xe6 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 591 + 0x19 bytes	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes

Comment 22

[Andreas Gal :gal]

Verified on MacOSX with current mc and jit on. Please feel to re-open (again) if you still hit this (sorry for the WFM-close-WFM-close cycle but I will WFM this kind of bugs once I can't reproduce it but feel free to re-open).

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre ID:20081002033404

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre ID:20081002020319

Comment 24

[timeless]

comment 21 is bug 469233
comment 4/comment 15: anything w/ jsd is probably the same