468506 - "can't convert Call to string" exception when adding a debugger statement to the jquery Mochitest

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

Attachment: 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]]

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]

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]

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)]

does this happen with earlier versions of Firebug? e.g., b1 or 2?

Comment 5

[John J. Barton]

Note that this message does *not* come through jsd.onError() which is itself a bug.

Comment 6

[John J. Barton]

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) (inactive)]

Attachment: 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]

(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) (inactive)]

(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]]

That's r=me with testcase added.

/be

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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)]

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]

(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) (inactive)]

http://hg.mozilla.org/tracemonkey/rev/7a277b27a659

Comment 15

[Rob Campbell [:rc] (:robcee)]

Do we have an ETA on landing this in m-c and 1.9.2?

Comment 16

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/7a277b27a659

Comment 17

[John J. Barton]

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.

Comment 18

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a04c9aa22774