Closed Bug 1058392 Opened 7 years ago Closed 6 years ago
Error when prettyprinting jsval or jsid
mrbkap and efaust report getting TypeErrors thrown when trying to prettyprint. Example: #10 0x00007f02e44fa7b7 in mozilla::jsipc::WrapperOwner::set (this=0x7f02d9d63690, cx=0x7f02d9db48c0, proxy=(JSObject * const) 0x7f02cfcca540 [object Proxy], Python Exception <class 'TypeError'> 'gdb.Value' object cannot be interpreted as an integer: receiver=(JSObject * const) 0x7f02cfcca540 [object Proxy], id=$jsid(), strict=false, vp=$jsval((JSObject *) 0x7f02d4f035b0 [object Array])) at /home/mrbkap/work/main/mozilla/js/ipc/WrapperOwner.cpp:440 On irc, mrbkap gave the following STR: mrbkap sfink: There is almost certainly an easier way to reproduce, but I've been doing: sfink: start an e10s window and navigate to a page with a textarea sfink: attach to the *child* process and put a breakpoint in js::AutoEnterPolicy::reportErrorIfExceptionIsNotPending sfink: right click in the textarea sfink: there should be a few failures in the stack trace. I tried this, but did not get a breakpoint hit (see eg http://people.mozilla.org/~sfink/textarea.html ). I switched to js::AutoEnterPolicy::AutoEnterPolicy and immediately got a breakpoint hit, but the stack was fine. gdb show version says "GNU gdb (GDB) Fedora 7.5.1-42.fc18" My stack: #0 js::AutoEnterPolicy::AutoEnterPolicy (this=0x7fff2d4b5500, cx=0x7f6579f1d340, handler= 0x7f657ecadd30 <xpc::XrayWrapper<js::CrossCompartmentWrapper, xpc::DOMXrayTraits>::singleton>, wrapper=(JSObject * const) 0x7f6569793200 [object Proxy], id=$jsid("type"), act=1, mayThrow=true) at /home/sfink/src/MI-GC/js/src/jsproxy.h:475 #1 0x00007f657a81b144 in js::Proxy::get (cx=0x7f6579f1d340, proxy= (JSObject * const) 0x7f6569793200 [object Proxy], receiver= (JSObject * const) 0x7f6569793200 [object Proxy], id=$jsid("type"), vp=JSVAL_VOID) at /home/sfink/src/MI-GC/js/src/jsproxy.cpp:2379 #2 0x00007f657a93a6a7 in GetPropertyOperation (vp=..., lval=..., pc=<optimized out>, script=..., fp=<optimized out>, cx=0x7f6579f1d340) at /home/sfink/src/MI-GC/js/src/vm/Interpreter.cpp:251 #3 Interpret (cx=cx@entry=0x7f6579f1d340, state=...) at /home/sfink/src/MI-GC/js/src/vm/Interpreter.cpp:2381 #4 0x00007f657a945b88 in js::RunScript (cx=cx@entry=0x7f6579f1d340, state=...) at /home/sfink/src/MI-GC/js/src/vm/Interpreter.cpp:411 #5 0x00007f657a93924e in js::Invoke (cx=cx@entry=0x7f6579f1d340, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/sfink/src/MI-GC/js/src/vm/Interpreter.cpp:483 #6 0x00007f657a9467cb in js::Invoke (cx=0x7f6579f1d340, thisv=..., fval=..., argc=1, argv= 0x7fff2d4b66d0, rval=JSVAL_VOID) at /home/sfink/src/MI-GC/js/src/vm/Interpreter.cpp:520 #7 0x00007f657a7994cc in JS_CallFunctionValue (cx=0x7f6579f1d340, obj= (JSObject * const) 0x7f656e68c780 [object Object], fval= $jsval((JSObject *) 0x7f656cf5bb00 [object Function "ClickEventHandler.handleEvent"]), args=..., rval=JSVAL_VOID) at /home/sfink/src/MI-GC/js/src/jsapi.cpp:4982 #8 0x00007f657bd9dc52 in nsXPCWrappedJSClass::CallMethod (this=0x7f656e85cdd0, wrapper=<optimized out>, methodIndex=3, info_=0x7f6572788eb0, nativeParams=0x7fff2d4b6900) at /home/sfink/src/MI-GC/js/xpconnect/src/XPCWrappedJSClass.cpp:1258 #9 0x00007f657b8762cb in PrepareAndDispatch (self=0x7f656fb369a0, methodIndex=<optimized out>, args=<optimized out>, gpregs=0x7fff2d4b69c0, fpregs=0x7fff2d4b69f0) at /home/sfink/src/MI-GC/xpcom/reflect/xptcall/md/unix/xptcstubs_x86_64_linux.cpp:122
What OS and gdb version are you using?
I'm on Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-34-generic x86_64) and GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
FWIW you can get a full Python stack trace from gdb using: (gdb) set python print-stack full ... and then reproducing the bug. (If you have a very old gdb you'll need "maint set python print-stack on" instead.) The full trace should make it pretty obvious where the bug lies.
I looked into this a little more. First, it may be a problem because Ubuntu uses Python 3 but did an incomplete transition. I'm not totally sure since I didn't immmediately see what version included what. But you can see some info in this bug: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1241668 There's also a report here: https://bugzilla.mozilla.org/show_bug.cgi?id=947669#c1 I don't have a theory for why the problem would manifest in that spot. The bug can be worked around by finding the places where gdb.Value is used as an integer and then changing these to use an explicit cast, like int(v) or long(v) (the latter is better on Python 2 with gdb Values). The fix in gdb would seem to be to add an __index__ method to gdb.Value. I'll file a bug against gdb for this.
The gdb bug is https://sourceware.org/bugzilla/show_bug.cgi?id=17386
This bug is driving me nuts. This takes the advice given in comment 4. I figure I'll file bugs and attach them on a per-case basis. Jim, do you have a better strategy?
Attachment #8513004 - Flags: review?(jimb)
Comment on attachment 8513004 [details] [diff] [review] Easiest patch Review of attachment 8513004 [details] [diff] [review]: ----------------------------------------------------------------- I don't have an environment to reproduce this, but if it fixes it for you and tromey says it makes sense, sounds good to me.
Attachment #8513004 - Flags: review?(jimb) → review+
I can confirm that applying the patch locally made a sad "bt" into a happy "bt" for me. (A very fortuitous day for :mrbkap to provide a patch! Although I think I'm just also following in his footsteps here too because I'm seeing a variant on bug 1090592 for my mochitests too...)
Assignee: nobody → mrbkap
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.