jsdIStackFrame changes in Firefox 3.6b1
John J Barton
breakpoints failing. Eventually I figure out that the problem is that
jsdIStackFrame.callingFrame is null at XPCOM boundaries. Here is a js
stack from Firefox 3.5. The comparable FF 3.6 stack stops at net.js
(3958), so we can't see up to the application level.
chrome://firebug/content/debugger.js (155)
chrome://firebug/content/debugger.js (908)
file:///F:/bartonjj/projects/fireclipse/firebug/firebug/branches/firebug1.5/components/firebug-service.js
file:///F:/bartonjj/projects/fireclipse/firebug/firebug/branches/firebug1.5/components/firebug-service.js
chrome://firebug/content/debuggerHalter.js (6)
chrome://firebug/content/debugger.js (137)
chrome://firebug/content/debugger.js (152)
chrome://firebug/content/net.js (2823)
chrome://firebug/content/net.js (2778)
chrome://firebug/content/net.js (2686)
chrome://firebug/content/net.js (4009)
chrome://firebug/content/net.js (3958)
() <<<<< This one is Null in FF 3.6b1 nightly
file:///F:/bartonjj/projects/fireclipse/firebug/firebug/branches/firebug1.5/components/firebug-http-observer.js
file:///F:/bartonjj/projects/fireclipse/firebug/firebug/branches/firebug1.5/components/firebug-http-observer.js
()
http://www.janodvarko.cz/firebug/tests/BreakOnXHR/breakOnXHR.html (36)
http://www.janodvarko.cz/firebug/tests/BreakOnXHR/breakOnXHR.html (1)
I'll try to look at this in FF 3.7, but anyone has a thought on what
change may cause this please let me know.
jjb
John J. Barton
> As we are working on Firebug 1.5 for Firefox 3.6 we found some of our
> breakpoints failing. Eventually I figure out that the problem is that
> jsdIStackFrame.callingFrame is null at XPCOM boundaries.
I wonder if this is related to
http://code.google.com/p/fbug/issues/detail?id=2370
where a debug build crashes when I think it is hitting an assert for
callingFrame.
jjb
Boris Zbarsky
> As we are working on Firebug 1.5 for Firefox 3.6 we found some of our
> breakpoints failing. Eventually I figure out that the problem is that
> jsdIStackFrame.callingFrame is null at XPCOM boundaries.
> chrome://firebug/content/net.js (3958)
> () <<<<< This one is Null in FF 3.6b1 nightly
> file:///F:/bartonjj/projects/fireclipse/firebug/firebug/branches/firebug1.5/components/firebug-http-observer.js
So what actually happens here? The XPCOM component in
firebug-http-observer.js does what to get into net.js?
Did the frame actually report "()" as the filename in 3.5.x? Or is that
something Firebug makes up? If the latter, in what cases?
(As a note, I just looked at the JS_SaveFrameChain callers, but nothing
obvious in those changed since 3.5.x at first glance. It might be
worthwhile to binary search on nightlies to see when the behavior here
changed....)
-Boris
John J. Barton
> On 10/14/09 7:05 PM, John J Barton wrote:
>> As we are working on Firebug 1.5 for Firefox 3.6 we found some of our
>> breakpoints failing. Eventually I figure out that the problem is that
>> jsdIStackFrame.callingFrame is null at XPCOM boundaries.
>
>> chrome://firebug/content/net.js (3958)
>> () <<<<< This one is Null in FF 3.6b1 nightly
>> file:///F:/bartonjj/projects/fireclipse/firebug/firebug/branches/firebug1.5/components/firebug-http-observer.js
>>
>
> So what actually happens here? The XPCOM component in
> firebug-http-observer.js does what to get into net.js?
Calls observe():
http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/net.js#3938
>
> Did the frame actually report "()" as the filename in 3.5.x? Or is that
> something Firebug makes up? If the latter, in what cases?
I believe that the trace I posted before was from Components.stack, and
the () is a null filename.
Let's use a simpler stack dumper, and print it with window.dump():
this.getJSDStackDump = function(newestFrame)
{
var lines = [];
for (var frame = newestFrame; frame; frame = frame.callingFrame)
lines.push(frame.script.fileName + " (" + frame.line + ")");
return lines.join("\n");
};
---------------
Here is the result from 3.5.3:
chrome://firebug/content/debuggerHalter.js (6)
chrome://firebug/content/debugger.js (137)
chrome://firebug/content/net.js (2823)
chrome://firebug/content/net.js (2778)
chrome://firebug/content/net.js (2686)
chrome://firebug/content/net.js (4024)
chrome://firebug/content/net.js (3973)
file:/C:/bartonjj/projects/fireclipse/fbug/branches/firebug1.5/components/firebug-http-observer.js
(183)
file:/C:/bartonjj/projects/fireclipse/fbug/branches/firebug1.5/components/firebug-http-observer.js
(142)
http://www.janodvarko.cz/firebug/tests/BreakOnXHR/breakOnXHR.html (36)
http://www.janodvarko.cz/firebug/tests/BreakOnXHR/breakOnXHR.html (1)
-----------------
Here is the result from 3.6b1pre (also 3.7)
chrome://firebug/content/debuggerHalter.js (6)
chrome://firebug/content/debugger.js (137)
chrome://firebug/content/net.js (2823)
chrome://firebug/content/net.js (2778)
chrome://firebug/content/net.js (2686)
chrome://firebug/content/net.js (4193)
>
> (As a note, I just looked at the JS_SaveFrameChain callers, but nothing
> obvious in those changed since 3.5.x at first glance. It might be
> worthwhile to binary search on nightlies to see when the behavior here
> changed....)
(ok I have notes too: the problem above only happens so far inside of
the onDebugger breakpoint handler. Other stacks are the same on 3.6 and
3.5.)
jjb
Blake Kaplan
> (As a note, I just looked at the JS_SaveFrameChain callers, but nothing
> obvious in those changed since 3.5.x at first glance. It might be
> worthwhile to binary search on nightlies to see when the behavior here
> changed....)
There was one that did change, though the bug that changed it is still
security sensitive. In particular, the fix causes us to sever the stack chain
when calling through a SJOW to content code. How important is having the full
stack here? My general understanding is that since you're calling into content
code, the stuff we're lopping off is only firebug stuff that shouldn't be
important to the debugged code.
I was thinking about landing the offending patch on the 1.9.2 branch, how bad
would that be?
--
Blake Kaplan
John J. Barton
> Boris Zbarsky <bzba...@mit.edu> wrote:
>> (As a note, I just looked at the JS_SaveFrameChain callers, but nothing
>> obvious in those changed since 3.5.x at first glance. It might be
>> worthwhile to binary search on nightlies to see when the behavior here
>> changed....)
>
> There was one that did change, though the bug that changed it is still
> security sensitive. In particular, the fix causes us to sever the stack chain
> when calling through a SJOW to content code. How important is having the full
> stack here? My general understanding is that since you're calling into content
> code, the stuff we're lopping off is only firebug stuff that shouldn't be
> important to the debugged code.
I don't understand "...since you're calling into content code...". I
thought we should never do that and to my knowledge we never do.
Generally the oldest frames are content code. Then there will some magic
(or mess, depending on your point of view), then debugger frames. For
example, the developer puts
debugger;
in foo() called by bar(). We see
onDebugger
magic
foo
bar
To show this to a developer we omit some frames so they only see:
foo
bar
How many frames to omit? Well I run some test cases and omit frames
until the stack looks right.
If components are involved then the story similar but there will be in
addition may be more magic frames. This is an issue for Chromebug only
so there I usually just leave whatever we get from jsd.
>
> I was thinking about landing the offending patch on the 1.9.2 branch, how bad
> would that be?
Of course I can't guess since I don't understand the case.
jjb
Blake Kaplan
> I don't understand "...since you're calling into content code...". I
> thought we should never do that and to my knowledge we never do.
Except when the XHR spy is called and you forward to the normal
onreadystatechange function. Or whenever you get the string representation of
a local variable you call toString on the content code. That is what I mean by
"calling into content code".
> Generally the oldest frames are content code. Then there will some magic
> ...
> How many frames to omit? Well I run some test cases and omit frames
> until the stack looks right.
Ideally, magic() shouldn't run on the same "thread" (in JS engine parlance,
this translates to "JSContext") as the debugged code. It changes the state of
the context, is scary from a security POV and causes the JS engine to have to
do a bunch of work to clean up before running code e.g. in
JS_EvaluateUCInStackFrame.
I'll grant that the last time I looked, the problem stemmed from a problem in
XPConnect and the precise way that jsd* used wrappedJS objects. But I guess
that's a separate issue to tackle later.
From talking to timeless on IRC, I realized that your example might be
entirely unrelated to any changes I made. How, exactly, can I reproduce your
problem?
--
Blake Kaplan