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
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.
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
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.
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.
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.
(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.
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?
We seem to be crashing in jsd_*. Does SeaMonkey use the debugger interface for something?
(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.
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?
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. :(
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
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....
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.
(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
Filed Bug 454561, disable JSD by default in SeaMonkey (almost for the Release-Builds).
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.
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.
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
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
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).
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