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

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: Waldo, Assigned: mrbkap)

Tracking

Trunk
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9.2 +
wanted1.9.2 +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 final-fixed)

Details

(Whiteboard: [firebug-p1] fixed-in-tracemonkey)

Attachments

(2 attachments)

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

8 years ago
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

8 years ago
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
Flags: blocking1.9.2?
Whiteboard: [firebug-p1]
does this happen with earlier versions of Firebug? e.g., b1 or 2?
Keywords: regressionwindow-wanted

Comment 5

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

Comment 6

8 years ago
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()
(Assignee)

Comment 7

8 years ago
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.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #414391 - Flags: review?(brendan)

Comment 8

8 years ago
(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
(Assignee)

Comment 9

8 years ago
(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.
Attachment #414391 - Flags: review?(brendan) → review+
That's r=me with testcase added.

/be
Flags: in-testsuite?
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.
Flags: wanted1.9.2+
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

8 years ago
(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.
(Assignee)

Comment 14

8 years ago
http://hg.mozilla.org/tracemonkey/rev/7a277b27a659
Keywords: regressionwindow-wanted
Whiteboard: [firebug-p1] → [firebug-p1] fixed-in-tracemonkey
Flags: blocking1.9.2? → blocking1.9.2+
Do we have an ETA on landing this in m-c and 1.9.2?

Comment 16

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

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 17

8 years ago
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

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a04c9aa22774
status1.9.2: --- → final-fixed
You need to log in before you can comment on or make changes to this bug.