Closed Bug 595743 Opened 9 years ago Closed 9 years ago
Crash [@ jsd
_Function Call Hook ] [@ XUL@0xba0d49 ] with Firebug or Venkman open, [@ jsd _Lock ]
str: 1. load any webpage 2. open Firebug 3. folow link on webpage AR: crash crash reports bp-2ea1269d-8199-4f4e-b677-0a69c2100912 bp-1a1dc3ea-0ff8-4c71-82ba-239b52100912 bp-d01e0361-3d3a-448e-adb7-4a26e2100912 bp-10374f4f-de7e-4b4a-854a-835422100912 no crash http://hg.mozilla.org/mozilla-central/rev/73ab2c3c5ad9 http://hg.mozilla.org/mozilla-central/rev/16eac4b8b8e0 <-- hourly crashes: http://hg.mozilla.org/mozilla-central/rev/cd3c926a7413 http://hg.mozilla.org/mozilla-central/rev/8a6a5cf00da7 <-- hourly http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16eac4b8b8e0&tochange=8a6a5cf00da7 jaegermonkey landing is most suspect.
we should reevaluate Firebug bugs after something like my patch in bug 595243 has been applied and used.
Also on Windows: http://crash-stats.mozilla.com/report/index/bp-d9f24671-db9f-4d2a-91f8-dfbad2100913 Firebug installed but not open in any of my tabs
OS: Mac OS X → All
Hardware: x86 → All
> Firebug installed but not open in any of my tabs If the status bar icon is orange, then jsd is active. You may have minimized Firebug rather than turned it off.
(In reply to comment #1) > we should reevaluate Firebug bugs after something like my patch in bug 595243 > has been applied and used. How can bug 595243 help here? A switch set by an addon should not allow a crash right? Or more appropriately, a switch not set by addon.
(In reply to comment #4) > (In reply to comment #1) > > we should reevaluate Firebug bugs after something like my patch in bug 595243 > > has been applied and used. > > How can bug 595243 help here? A switch set by an addon should not allow a crash > right? Or more appropriately, a switch not set by addon. Yes, that is not good. Debuggers are required to set debug mode before trying to do anything, but not doing that is supposed to be a jsdbgapi error, not a crash. I think the underlying problem there is that we should not even call debug hooks if debug mode is off.
UUID d9f24671-db9f-4d2a-91f8-dfbad2100913 Frame Module Signature Source 0 xul.dll jsd_FunctionCallHook js/jsd/jsd_step.c:281 1 xul.dll InlineReturn 2 xul.dll jsd_CallExecutionHook js/jsd/jsd_hook.c:190 3 xul.dll js_InternalThrow 4 xul.dll JaegerThrowpoline js/src/methodjit/MethodJIT.cpp:638 5 mozcrt19.dll arena_dalloc_small obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4153 6 xul.dll js::Invoke js/src/jsinterp.cpp:614 7 @0x9927e23
I tried to patch the source and set debugMode to true by default (for all compartments), but it doesn't seem to help. This problem is critical and prevents further Firebug testing on Firefox 4.0 Honza
bp-760ada18-c4cc-473f-8662-cd7ad2100914 too. Crashes on tuenti.com (the biggest social network in Spain, yes, more than Facebook) (and I don't have Firebug enabled on the page, but installed)
I get it with Gmail, Facebook and Kongregate. Installed but not open/active.
#3 topcrash on the trunk. we should try to get this fixed before b7.
would also rank higher if you count crashes from the dup'ed bug 595837 -- crashes in js_Lock. a lot of these look pretty close to start up. Correlation to startup or time of session 130 total crashes for jsd_Lock on 20100913-crashdata.csv 55 startup crashes inside 30 sec. 85 startup crashes inside 3 min. 63 repeated crashes inside 3 min. of last crash Correlation to startup or time of session 471 total crashes for jsd_FunctionCallHook on 20100913-crashdata.csv 195 startup crashes inside 30 sec. 299 startup crashes inside 3 min. 197 repeated crashes inside 3 min. of last crash
We know exactly what's causing this--we shouldn't try to call any debug hooks from the methodjit when debug mode is off (which it always is, pending further work on jsd/Firebug). What happens now is that the call hook gets skipped when calling thru ICs, but we try to call the return hook when the call returns. But the return hook can't be called correctly unless the call hook ran earlier.
Is there a bug open on enabling JS debugging for FF 4.0b7? In addition to solving the problem here which occurs with then debugMode is on, we also need the mode to be switch off/on. If that bug exists, I want to nominate it for blocking since otherwise we don't have js debug.
(In reply to comment #15) > Is there a bug open on enabling JS debugging for FF 4.0b7? The metabug is bug 563000. > In addition to > solving the problem here which occurs with then debugMode is on, we also need > the mode to be switch off/on. That's bug 595243. > If that bug exists, I want to nominate it for > blocking since otherwise we don't have js debug.
The ETA here is past due; can we get a progress update, please?
Please note that we have now created a branch for beta 7 work. In addition to landing your fix on mozilla-central default, please also land it on mozilla-central GECKO20b7pre_20101006_RELBRANCH (note: when landing on mozilla-central default, you will be given priority in the landing queue at https://wiki.mozilla.org/LandingQueue )
Whiteboard: [firebug-p1][ETA-10/05] → [firebug-p1][ETA-10/05][to be fixed by bug 595243?]
bug 596456 has been marked works for me because its no longer reproducable. no crashes XUL@0xba0d49 or jsd_Lock in the last 8 days the jsd_FunctionCallHook signature is still around in small volume (~1 crash per day) as of 4.0b8pre2010101604 that could be some small residual bug that existed before this bug was reported and people saw a spike in firebug interaction crashes.
With Firebug 1.7x.0a4 + YSlow 2.10+ Firecookie 1.1b8 + Page speed 1.9.1 Minefield 4.0beta8pre NOT crashed.
I hit bug 606357 first if I try to repro this. Bug 606357 is currently nominated for blocking. It doesn't make sense to have this block unless bug 606357 also blocks: fixing this bug is useless unless bug 606357 is also fixed. So, either both should block or neither.
Depends on: 606357
If I force debug mode on and comment out the compartment-check assertions, I can follow the STR with no crash. So, I think this is just a symptom of not having debug mode turned on, and it will be fixed by bug 595243.
Not sure if this is the same problem, but I have a similar one: When Firebug is open and I try to open the following URL Minefield nightly crashes: http://www.chip.de/bestenlisten/Bestenliste-Solid-State-Disks-SSD--index/detail/id/762/ (win 7, 64bit)
(In reply to comment #25) > Not sure if this is the same problem, but I have a similar one: > When Firebug is open and I try to open the following URL Minefield nightly > crashes: > http://www.chip.de/bestenlisten/Bestenliste-Solid-State-Disks-SSD--index/detail/id/762/ > (win 7, 64bit) Confirm this situation. Firebug open. Open your URL. Minefield crashed. I submited crash report. I have Firebug 1.7x.0a4 + YSlow 2.10+ Firecookie 1.1b8 + Page speed 1.9.1, Win 7, 32 bit.
My crash report: http://crash-stats.mozilla.com/report/index/bp-a77b3a28-0759-4f3e-9eeb-3bfba2101027 This leads to bug 595351
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=595243 is fixed, what is state of THIS bug now day?
This will be available starting with tonight's nightly. Can we get a crash analysis tomorrow? Thanks.
You will need either Firebug 1.7a5 (First week of Nov. 2010) or you will need to svn co https://fbug.googlecode.com/svn/branches/firebug1.7 and point your extension directory at the result. In the latter case, let me know how it goes, we've not tested jsd.asyncOn().
The crashes stop either way. I hope the functionality was tested when the other bug was closed.
The same crash also happens when Venkman gets started in a most recent Minefield build on OS X: http://crash-stats.mozilla.com/report/index/1049d6a8-9076-41c3-b016-389852101031 The patch on bug 595243 landed today on m-c. So this crash should hopefully be fixed in one of the next hourly builds or tomorrows nightly.
Summary: Crash [@ jsd_FunctionCallHook ] [@ XUL@0xba0d49 ] with Firebug open, [@ jsd_Lock ] → Crash [@ jsd_FunctionCallHook ] [@ XUL@0xba0d49 ] with Firebug or Venkman open, [@ jsd_Lock ]
#33: it looks to me today's build should already contain that patch
So a recent tinderbox build doesn't crash when opening Venkman but it produces the following error now: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [jsdIDebuggerService.on]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: chrome://venkman/content/venkman-debugger.js :: initDebugger :: line 131" data: no] Can someone see the same message with Firebug? Should this be filed as a new bug?
This is expected. venkman and firebug need a fix to use the new API sayrer implemented. I will close this bug based on #35. If we need to hold b7 until venkman and firebug are fixed, please file a bug for that and nominate it.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
File against Venkman as it is not using the new API. Firebug is using it now, but the latest nightly/Firebug combo is very flaky. I was only lucky on one web page where I got to see the script panel.
Filed bug 608685 for the Venkman update. Thanks Andreas.
Whiteboard: [firebug-p1][ETA-10/05][to be fixed by bug 595243?] → [firebug-p1][fixed by bug 595243]
Target Milestone: --- → mozilla2.0b7
Crash Signature: [@ jsd_FunctionCallHook ] [@ XUL@0xba0d49 ] [@ jsd_Lock ]
You need to log in before you can comment on or make changes to this bug.