jsdIDebuggerService crashing FF 2.0

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

jsdIDebuggerService crashing FF 2.0

John J Barton
Hi.  I have a FF extension that uses jsdIDebuggerService to extract
information about errors in eval() code.  It's working but it crashes FF
sometime after it has done its analysis. The code is all Javascript. I
set errorHook, debugHook, topLevelHook, and scriptHook, turn jsds.on().
As the page runs I store jsdIScript objects in an array but they are all
deleted again.  I do issue dump() and send  a nsIScriptError to
nsIConsoleService.  I also have a nsIWebProgressListener and a
consoleListener but these have been working for a while without crashing
the browser.

Any suggestions?  The crashes seem to happen when I do other things
after running my code; they seem a bit random, but then I have been
making lots of changes up to now.

Thanks,
John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

James Ross
John J. Barton wrote:
> Any suggestions?  The crashes seem to happen when I do other things
> after running my code; they seem a bit random, but then I have been
> making lots of changes up to now.

Generally, the debugging objects are quite flimsy, and liable to
disappear without notice, but it could be almost anything, really;
you're going to need one of:
   - a debug build you can get a stack trace from yourself, or
   - talkback report IDs from the crashes.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John J Barton
James Ross wrote:
> John J. Barton wrote:
>> Any suggestions?  The crashes seem to happen when I do other things
>> after running my code; they seem a bit random, but then I have been
>> making lots of changes up to now.
>
> Generally, the debugging objects are quite flimsy, and liable to
> disappear without notice, but it could be almost anything, really;
> you're going to need one of:
>   - a debug build you can get a stack trace from yourself, or

I looked in to this, I'd prefer it but the tool chain is unusual
and quite complicated.

>   - talkback report IDs from the crashes.
Here is the most recent four of about 30:
TB27213209K, TB27213184Y, TB27211396E, TB27211391G
what can be done with these?

Thanks,
John.

>
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John J Barton
I figured out how to do my work without topLevelHook and scriptHook and
so far FF is not being crashed.

John J. Barton wrote:

> James Ross wrote:
>> John J. Barton wrote:
>>> Any suggestions?  The crashes seem to happen when I do other things
>>> after running my code; they seem a bit random, but then I have been
>>> making lots of changes up to now.
>>
>> Generally, the debugging objects are quite flimsy, and liable to
>> disappear without notice, but it could be almost anything, really;
>> you're going to need one of:
>>   - a debug build you can get a stack trace from yourself, or
>
> I looked in to this, I'd prefer it but the tool chain is unusual
> and quite complicated.
>
>>   - talkback report IDs from the crashes.
> Here is the most recent four of about 30:
> TB27213209K, TB27213184Y, TB27211396E, TB27211391G
> what can be done with these?
>
> Thanks,
> John.
>
>>
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

timeless-3
In reply to this post by John J Barton
On Dec 12, 6:56 pm, "John J. Barton" <[hidden email]>
wrote:
> >   - talkback report IDs from the crashes.Here is the most recent four of about 30:
> TB27213209K, TB27213184Y, TB27211396E, TB27211391G
> what can be done with these?

start by visiting http://talkback-public.mozilla.org/search/start.jsp

Note that as of this writing talkback doesn't seem to be very
responsive, so be patient, or try again another day. You can search by
id, and you'll get a stack trace.

>From there, search for the signature in bugzilla.mozilla.org,
https://bugzilla.mozilla.org/query.cgi

If you don't find a bug, please file one. include the keyword 'crash',
[@ sign::nature] in the summary, and the stack trace in the
description.

you can also visit irc.mozilla.org and ask for help chasing it. problem
you'll end up talking to James Ross, or myself (but please don't expect
us to be around on weekends. sometimes we sleep and such).

Unfortunately, your first stack looks like this:
Incident ID: 27213209
Stack Signature js_MarkGCThing 19bb9def
Product ID Firefox2
Build ID 2006101023
Trigger Time 2006-12-11 22:02:56.0
Platform Win32
Operating System Windows NT 5.1 build 2600
Module js3250.dll + (0001f26c)
URL visited
User Comments jsds.on()
Since Last Crash 16 sec
Total Uptime 3891028 sec
Trigger Reason Access violation
Source File, Line
No. c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/js/src/jsgc.c,
line 2351
Stack Trace
js_MarkGCThing  [mozilla/js/src/jsgc.c, line 2351]
MarkGCThingChildren  [mozilla/js/src/jsgc.c, line 1971]
js_MarkGCThing  [mozilla/js/src/jsgc.c, line 2352]
js_GC  [mozilla/js/src/jsgc.c, line 2745]
JS_GC  [mozilla/js/src/jsapi.c, line 1944]
nsAppStartup::Run
[mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 152]
main  [mozilla/browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x16fd7 (0x7c816fd7)

Which is useless. it just means that there's an object that probably
reached the dead state while something had a reference to it. In
general stacks with JS_GC in them are not very easy to solve (ideally
you manage to create a very simple reproducable testcase, and then
build a debug build and spend a long time learning about spidermonkey).

Note that not all crashes are the same, so while [@ js_MarkGCThing]
would be the signature, and while the stack probably matches a dozen
bugs, if the bugs don't talk about using jsd to trigger it, it's
/probably/ not the bug you want, and if you don't find a match that
does mention jsd/venkman/firebug, you'd want to use a new one.

Certainly if there's a change that you made to avoid the crash,
explaining (and providing sample code for crashing/simple change that
doesn't crash code) that's usually very helpful.

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John J Barton
I have very reproducable crash from a simple script that has an eval()
with a js error in the evaluated string. I am having trouble isolating
the problem because the code is in xpcom implemented in javascript
(firebug-service.js) I can't seem to use dump() and logging to the JS
error console does not seem to flush all content before the crash.

Talkback ID 27823951 shows that the problem is an unset return value.
But actually the stack trace does not make a lot of sense.  I guess my
hook is being run by CallExecutionHook and thus there is code that does
not show up in the trace bound in to the hook() that must then call
getValueWrappedJSVal.

jsd_GetValueWrappedJSVal  [mozilla/js/jsd/jsd_val.c, line 284]
jsd_CallExecutionHook  [mozilla/js/jsd/jsd_hook.c, line 178]
jsd_TrapHandler  [mozilla/js/jsd/jsd_scpt.c, line 735]
JS_HandleTrap  [mozilla/js/src/jsdbgapi.c, line 213]
js_Interpret  [mozilla/js/src/jsinterp.c, line 4554]
js_Execute  [mozilla/js/src/jsinterp.c, line 1644]
obj_eval  [mozilla/js/src/jsobj.c, line 1360]


Any hints or suggestions would be welcome.

Thanks,
John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John J Barton
Nevermind.  After a bit more trial and error I figured it out.

Here is the code that failed in my executionHook:

                var evaled = frame.eval(expr, eval_name, 1, result);
               
                if (evaled)
                {
                        val.value = result.value.getWrappedValue();
================================================^^^^^^^^^^^^^^^^^
                        return RETURN_VALUE;
                }
                else
                {
                        val.value = result.value.getWrappedValue();
                        return RETURN_THROW_WITH_VAL;
                }
The line that works is
                        val.value = result.value;
So I guess that by un-wrapping the result from the frame.eval() I caused
my caller grief because it was expecting to un-wrap.  Since I passed
back an un-wrapped value, the caller crashed. (Kudos to venkman once
again, the ultimate in example code).

Or at least that is what I think now...

John.



John J. Barton wrote:

> I have very reproducable crash from a simple script that has an eval()
> with a js error in the evaluated string. I am having trouble isolating
> the problem because the code is in xpcom implemented in javascript
> (firebug-service.js) I can't seem to use dump() and logging to the JS
> error console does not seem to flush all content before the crash.
>
> Talkback ID 27823951 shows that the problem is an unset return value.
> But actually the stack trace does not make a lot of sense.  I guess my
> hook is being run by CallExecutionHook and thus there is code that does
> not show up in the trace bound in to the hook() that must then call
> getValueWrappedJSVal.
>
> jsd_GetValueWrappedJSVal  [mozilla/js/jsd/jsd_val.c, line 284]
> jsd_CallExecutionHook  [mozilla/js/jsd/jsd_hook.c, line 178]
> jsd_TrapHandler  [mozilla/js/jsd/jsd_scpt.c, line 735]
> JS_HandleTrap  [mozilla/js/src/jsdbgapi.c, line 213]
> js_Interpret  [mozilla/js/src/jsinterp.c, line 4554]
> js_Execute  [mozilla/js/src/jsinterp.c, line 1644]
> obj_eval  [mozilla/js/src/jsobj.c, line 1360]
>
>
> Any hints or suggestions would be welcome.
>
> Thanks,
> John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

James Ross
John J. Barton wrote:
> So I guess that by un-wrapping the result from the frame.eval() I caused
> my caller grief because it was expecting to un-wrap.  Since I passed
> back an un-wrapped value, the caller crashed. (Kudos to venkman once
> again, the ultimate in example code).
>
> Or at least that is what I think now...

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/jsd/idl/jsdIDebuggerService.idl&rev=1.33&mark=674-675#664

I hate to say RTFM but, well, it does say jsdIValue there. ;)

(Personally, I'd have thought XPConnect should shit itself long before
this got to JSD code, but I've also learnt to never trust XPConnect to
do its job right.)

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John Bandhauer
James Ross wrote:

> John J. Barton wrote:
>> So I guess that by un-wrapping the result from the frame.eval() I
>> caused my caller grief because it was expecting to un-wrap.  Since I
>> passed back an un-wrapped value, the caller crashed. (Kudos to venkman
>> once again, the ultimate in example code).
>>
>> Or at least that is what I think now...
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/jsd/idl/jsdIDebuggerService.idl&rev=1.33&mark=674-675#664 
>
>
> I hate to say RTFM but, well, it does say jsdIValue there. ;)
>
> (Personally, I'd have thought XPConnect should shit itself long before
> this got to JSD code, but I've also learnt to never trust XPConnect to
> do its job right.)
>

James,

XPConnect did its job exactly right here. The *real* bug here is in
jsd_xpc.cpp. That bug ought to be fixed.

But first. Before spreading the notion that XPConnect is broken, you
should try to understand what job it is doing. Part of the idea of
XPConnect is that it allows JS coders to minimally implement xpcom
interfaces. This means that it automatically builds a wrapper around a
passed in JSObject without requiring that the object implement all
methods of the (scriptable) xpcom interface. JavaScript is dynamic.
The methods an object has at one point in time might not be the
methods it has at another point in time. XPConnect allows the JS coder
to 'claim' that a given JSObject implements a given scriptable xpcom
interface. The coder makes that 'claim' by simply using the object in
a context that requires an interface. It is that simple by design.

If at method call time a given method is found to not exist on the
JSObject (or its inheritance chain) then XPConnect's stub for the
interface method returns an error code (while properly handling all
in, out, and in/out params). That is, XPConnect makes it so that the
wrapper does in fact fully implement the xpcom interface as declared
in xpidl.

There was some discussion early on about allowing for a way to declare
in xpidl that a given interface was *callable* via script, but not
*implementable* via script. Though that might have been useful in this
case, we decided then that this was an unnecessary and potentially
harmful complication.

I'm sorry that your expectations are incorrect. But, XPConnect worked
exactly as designed here. The JS coder provided a JSObject in a place
where an object implementing the jsdIValue interface was required.
XPConnect then built a wrapper compliant with that interface.

The bug is in jsds_ExecutionHookProc's use of the returned value. See:

http://lxr.mozilla.org/seamonkey/source/js/jsd/jsd_xpc.cpp#688

It calls GetJSDValue() on the object but ignores the nsresult. As it
happens, GetJSDValue maps to a [noscript] attribute on the interface,
so XPConnect returns an error code to the caller.

But, that jsd_xpc code (incorrectly) ignores the nsresult and assumes
that it got a useful answer from the method call. So, it goes ahead
and calls JSD_GetValueWrappedJSVal with a garbage parameter. That is
the bug. And it ought to be fixed.

As it happens, in a debug build of JSD, JSD_GetValueWrappedJSVal would
do various validations of the passed in params. Though, in this case,
the param passed in is not even pre-initialized.

Anyway, I suggest that you file a JSD bug and fix the real problem.

John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

James Ross
John Bandhauer wrote:
> XPConnect did its job exactly right here. The *real* bug here is in
> jsd_xpc.cpp. That bug ought to be fixed.
>
> But first. Before spreading the notion that XPConnect is broken, you
> should try to understand what job it is doing.

I didn't say it was broken here, I said I don't *trust* it here. That's
from experience of it being broken in other places, and I find your
arrogant and patronising attitude very worrying.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John Bandhauer
James Ross wrote:

> John Bandhauer wrote:
>> XPConnect did its job exactly right here. The *real* bug here is in
>> jsd_xpc.cpp. That bug ought to be fixed.
>>
>> But first. Before spreading the notion that XPConnect is broken, you
>> should try to understand what job it is doing.
>
> I didn't say it was broken here, I said I don't *trust* it here. That's
> from experience of it being broken in other places, and I find your
> arrogant and patronising attitude very worrying.
>

Ha! Let's not get too serious here.

I'm not sure why you should find my attitude worrying; I'm not an active
contributor, so I'm not likely to do any new damage to anything.

I was merely trying to offer some insight into code that I wrote a long
time ago. I won't speak to the charge of arrogance :) But, I will say
that what you called "patronising" was simply my response to seeing
people working around a very real software defect when filing a bug (and
perhaps finding and fixing the problem) was in order. I'm sorry if my
explanation of the XPConnect behavior was too elementary for you, but I
assume that other people might read it and I was trying to explain it in
a reasonable and complete fashion.

Your statements... "(Personally, I'd have thought XPConnect should shit
itself long before this got to JSD code, but I've also learnt to never
trust XPConnect to do its job right.)" ...suggest that you didn't
understand what XPConnect was really doing in this case.

I'd be more impressed by *active* mozilla developers if *someone* went
to the trouble of filing a bug on JSD (citing the info I gave
previously) so that this bug perhaps gets fixed one day.

John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

James Ross
John Bandhauer wrote:
> I'd be more impressed by *active* mozilla developers if *someone* went
> to the trouble of filing a bug on JSD (citing the info I gave
> previously) so that this bug perhaps gets fixed one day.

The bug's on file (bug 365363) but even with a patch we have so few
active reviewers it'll take weeks to get in. I've got about 7 patches
already which are waiting for review. Oh well.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIDebuggerService crashing FF 2.0

John J Barton
In reply to this post by John Bandhauer
John Bandhauer wrote:


John and James, I appreciate your information, very helpful.

>
> I'd be more impressed by *active* mozilla developers if *someone* went
> to the trouble of filing a bug on JSD (citing the info I gave
> previously) so that this bug perhaps gets fixed one day.

Mozilla is --like all large systems -- complex and inconsistently
documented. And it is but one part of the systems people work on.  I
think this gives even dedicated folks pause: is my problem a bug? RFTM?
Working as designed? Very difficult to say in many cases.  And sometimes
developers on large systems don't take kindly to inaccurate bug reports,
  scaring off some contributors (I don't know about Mozilla; I don't
know enough to report bugs on it).

Mozilla has an additional handicap: it has a monolithic cross-platform
build system with many dependencies.  I've built a lot of linux apps and
Java apps to debug, but Mozilla is just out of reach in terms of time
and energy.  Even tools like xpidl are only available through extensive
work.  Of course I realize that Mozilla also solves many important
problems by accepting this build system, but I just want explain why I
can't be impressive ;-).

John.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger