Last Comment Bug 468506 - "can't convert Call to string" exception when adding a debugger statement to the jquery Mochitest
: "can't convert Call to string" exception when adding a debugger statement to ...
Status: RESOLVED FIXED
[firebug-p1] fixed-in-tracemonkey
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal with 1 vote (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-08 13:40 PST by Jeff Walden [:Waldo] (remove +bmo to email)
Modified: 2009-12-19 23:32 PST (History)
7 users (show)
mbeltzner: blocking1.9.2+
shaver: wanted1.9.2+
brendan: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
final-fixed


Attachments
Patch to apply to reproduce bug (771 bytes, patch)
2008-12-08 13:40 PST, Jeff Walden [:Waldo] (remove +bmo to email)
no flags Details | Diff | Splinter Review
Proposed fix (702 bytes, patch)
2009-11-24 16:30 PST, Blake Kaplan (:mrbkap)
brendan: review+
Details | Diff | Splinter Review

Description Jeff Walden [:Waldo] (remove +bmo to email) 2008-12-08 13:40:53 PST
Created attachment 351968 [details] [diff] [review]
Patch to apply to reproduce bug

Apply the attachment to a clean tree (in tracemonkey I've applied it to revision dd0445447525, but that probably doesn't matter).  Then run:

$ TEST_PATH=dom/tests/mochitest/ajax/jquery/test_jQuery.html make -C $OBJDIR mochitest-plain

Doing so results in this error:

not ok - core module: addClass(String) Died on test #1: can't convert Call to string
Comment 1 Jeff Walden [:Waldo] (remove +bmo to email) 2008-12-08 14:11:56 PST
That was with the default setting of javascript.jit.content = true; if I change that to false, I get the following:

not ok - core module: $.makeArray Died on test #13: can't convert Call to string

Maybe we have two bugs here.  :-(
Comment 2 John J. Barton 2009-11-19 16:39:09 PST
I see this message in Chromebug or Firebug I can't tell. FF 3.6b4pre. category is XPConnect JavaScript. Then I get a bunch of these:
Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [jsdIDebuggerService.exitNestedEventLoop]" nsresult: "0x80004005 (NS_ERROR_FAILURE)
Comment 3 John J. Barton 2009-11-21 09:36:43 PST
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091121 Minefield/3.7a1pre

1. Install firebug 1.5b4, http://getfirebug.com/releases/firebug/1.5X
2. Open http://getfirebug.com/tests/content/script/debuggerKeyword/testPage.html
3. Open Firebug
4. reload
5. Push "Debugger in XHR" button.

The subject error message occurs, no file or line number. Firebug seems broken, continue and step buttons don't work.

Also 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b4pre) Gecko/20091121 Namoroka/3.6b4pre

New since November 18th, 2009
Comment 4 Rob Campbell [:rc] (:robcee) 2009-11-23 06:57:31 PST
does this happen with earlier versions of Firebug? e.g., b1 or 2?
Comment 5 John J. Barton 2009-11-24 15:03:11 PST
Note that this message does *not* come through jsd.onError() which is itself a bug.
Comment 6 John J. Barton 2009-11-24 15:41:17 PST
I happened to be debugging Firebug's error reporting and have a test case like this:
function testUnhandled() {
    dojo.string.trim(null);
}
function testHandled() {
    try {
        testUnhandled();
    } catch( e) {
        console.error( e);
    }
}
If we call testUnhandled from a web page button, all works. If we call testHandled() from a Web page button, we get the subject error. So I guess the problem here is on the try/catch logic and that explains why the message does not come out in jsd.onError()
Comment 7 Blake Kaplan (:mrbkap) 2009-11-24 16:30:49 PST
Created attachment 414391 [details] [diff] [review]
Proposed fix

JS_GetFrameThis was trying to avoid calling js_ComputeThis when it didn't have to. However, because of wrapping, call, and block objects, it can't.
Comment 8 John J. Barton 2009-11-24 16:32:48 PST
(I was typing this when comment 7 arrived)

The error only happens after we take a breakpoint, so it happens only after we call jsd.enterNestedEventLoop().  I was able to trap the exception and I see why the Error Console does not have a line number: the value in the exception object for lineNumber is 4294967295 and fileName is null. So we are writing on memory or picking up uninitialized values.

This on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091124 Minefield/3.7a1pre
Comment 9 Blake Kaplan (:mrbkap) 2009-11-24 16:36:30 PST
(In reply to comment #8)
> object for lineNumber is 4294967295 and fileName is null. So we are writing on
> memory or picking up uninitialized values.

4294967295 is 0xffffffff => -1 which means "no line number" and fileName being null means that we didn't know the file name.
Comment 10 Brendan Eich [:brendan] 2009-11-24 17:16:59 PST
That's r=me with testcase added.

/be
Comment 11 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-11-26 07:30:44 PST
Can I get a clear description of the impact here?  It sounds like it only affects the debugger keyword and certain specific contexts in FB more narrowly (per comment 8), so it doesn't *sound* like a blocker.  Wanted if it gets baked in time, which is to say in very very little time, though.
Comment 12 Rob Campbell [:rc] (:robcee) 2009-11-27 06:20:22 PST
We had two testcases that were failing with this error showing up in the console. I didn't fully understand the issue myself and this error appeared to be a side-effect of whatever was causing the problem. I'd like a better explanation of the impact from John as well as the subject of this message doesn't really describe the problem. It did sound like a regression to me, though possibly as a result of the way we're wrapping objects now in Firebug 1.5.
Comment 13 John J. Barton 2009-11-27 09:45:51 PST
(In reply to comment #11)
> Can I get a clear description of the impact here?  It sounds like it only
> affects the debugger keyword and certain specific contexts in FB more narrowly
> (per comment 8), so it doesn't *sound* like a blocker.
 
See comment 6 for a case that fails without 'debugger'. Based on this case and the behavior of the exception not being caught by normal exception handling leads me to suspect try/catch block is required. Also note that in the test page from comment 3 there are 4 other tests involving 'debugger'. They all pass.

Based on the original report, Firebug is not required. Rather I guess the problem depends upon the JIT being disabled, either by Firebug being active or the explicit pref. 

If the issue comes up on "stop in jsd while in a try block", Firebug will be broken.  There might be other conditions which narrow the scope, but I've hit it several times using Chromebug. 

> Wanted if it gets baked
> in time, which is to say in very very little time, though.

Then we should land this on mozilla-central while a test case is being created.

One other suggestion for the cost/benefit analysis: the change that caused this bug landed after Nov. 18. If we knew which change caused this we could weigh the value it adds against the pain it causes.
Comment 14 Blake Kaplan (:mrbkap) 2009-12-01 11:45:03 PST
http://hg.mozilla.org/tracemonkey/rev/7a277b27a659
Comment 15 Rob Campbell [:rc] (:robcee) 2009-12-04 06:03:05 PST
Do we have an ETA on landing this in m-c and 1.9.2?
Comment 17 John J. Barton 2009-12-07 14:25:46 PST
I just verified that our test case passes now with 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091207 Minefield/3.7a1pre

Now we just need it on FF 3.6.

Note You need to log in before you can comment on or make changes to this bug.