Closed Bug 595743 Opened 14 years ago Closed 14 years ago

Crash [@ jsd_FunctionCallHook ] [@ XUL@0xba0d49 ] with Firebug or Venkman open, [@ jsd_Lock ]

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: phiw2, Assigned: dmandelin)

References

Details

(Keywords: crash, regression, Whiteboard: [firebug-p1][fixed by bug 595243])

Crash Data

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
blocking2.0: --- → ?
> 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.
Whiteboard: [firebug-p1]
(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
Keywords: crash, regression
Summary: Crash [@ jsd_FunctionCallHook ] [@ XUL@0xba0d49 ] with Firebug open → Crash [@ jsd_FunctionCallHook ] [@ XUL@0xba0d49 ] with Firebug open, [@ jsd_Lock ]
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.
Depends on: 596456
blocking2.0: ? → beta7+
Assignee: general → sayrer
Whiteboard: [firebug-p1] → [firebug-p1][ETA-9/29]
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?
Whiteboard: [firebug-p1][ETA-9/29] → [firebug-p1][ETA-10/05]
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.
Just FYI, Javascript debugging in 4.0b8pre has no Javascript debug capability so I don't think we can conclude anything here: the feature is not being tested.

Nevertheless I expect that when Bug 595243 lands Sayre will make sure Firebug does not crash, and then this bug will be unnecessary. So I marked it depends so you will see when that happens.
Depends on: 595243
No longer depends on: 596456
With Firebug 1.7x.0a4 + YSlow 2.10+ Firecookie 1.1b8 + Page speed 1.9.1 Minefield 4.0beta8pre NOT crashed.
Assignee: sayrer → gal
Assignee: gal → dmandelin
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.
Depends on: 607174
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.
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: 14 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.