segv

4 views
Skip to first unread message

Steven Parkes

unread,
Feb 26, 2010, 6:55:06 PM2/26/10
to johnso...@googlegroups.com
Okay, I can consistently make johnson core. It's in a situation where ruby calls spidermonky calls ruby which raises an exception and calls spidermonky to tell it.

Valgrind detects thing are corrupt:

==14561== Invalid read of size 8
==14561== at 0xF15969C: js_FramePCToLineNumber (jsscript.cpp:1801)
==14561== by 0xF0B19EE: PopulateReportBlame(JSContext*, JSErrorReport*) (jscntxt.cpp:1317)
==14561== by 0xF0B1E9F: js_ReportErrorVA(JSContext*, unsigned int, char const*, __va_list_tag*) (jscntxt.cpp:1415)
==14561== by 0xF08B400: JS_ReportError (jsapi.cpp:5547)
==14561== by 0xF074150: report_ruby_error_in_js(JohnsonRuntime*, int, unsigned long) (conversions.cc:341)
==14561== by 0xF070AFD: call_ruby_from_js_va(JohnsonRuntime*, unsigned long*, unsigned long, unsigned long, int, __va_list_tag*) (js_land_proxy.cc:77)
==14561== by 0xF070D2E: call_ruby_from_js(JohnsonRuntime*, long*, unsigned long, unsigned long, int, ...) (js_land_proxy.cc:87)
==14561== by 0xF07105F: call(JSContext*, JSObject*, unsigned int, long*, long*) (js_land_proxy.cc:508)
==14561== by 0xF0FEBFF: js_Call (jsobj.cpp:5197)
==14561== by 0xF0F2123: js_Invoke (jsinterp.cpp:1362)
==14561== by 0xF194952: js_Interpret (jsops.cpp:2240)
==14561== by 0xF0F2173: js_Invoke (jsinterp.cpp:1370)
==14561== Address 0x7fefdf470 is not stack'd, malloc'd or (recently) free'd

It looks like there are JSStackFrame pointers that point below the top of the stack.

I'm going to keep looking at it, but if it rings any bells ...


Steven Parkes

unread,
Feb 26, 2010, 11:00:32 PM2/26/10
to johnso...@googlegroups.com
Ugh. Ruby's long jumping over spidermonkey.

Have you guys dealt with that before?

Steven Parkes

unread,
Feb 27, 2010, 8:12:30 PM2/27/10
to johnso...@googlegroups.com
Well, I'm getting together a nice little set of tools for tracing every freaking setjmp/longjmp in Ruby. I've got cooperating hacks to SM, Ruby, and Johnson so I can trace exactly the longjmp that is going to jump over a SM stack frame before it happens. Probably a better way to do it, but dang, a tricky mother to nail down.

Anyway, here's the call stack that's blowing chunks right now:

#1 0x000000000041b40b in rb_longjmp (tag=6, mesg=140101930867840) at eval.c:4693
#2 0x000000000041b52d in rb_exc_raise (mesg=140101930867840) at eval.c:4710
#3 0x00000000004c4dfd in rb_raise (exc=140102008913360, fmt=0x4c76d8 "wrong number of arguments (%d for 0)") at error.c:1058
#4 0x000000000041ed56 in rb_call0 (klass=140101977150680, recv=140101930878280, id=10233, oid=10233, argc=1, argv=0x7fffde85b200, body=0x7f6c089486f0, flags=0) at eval.c:5984
#5 0x00000000004204f8 in rb_call (klass=140101977150680, recv=140101930878280, mid=10233, argc=1, argv=0x7fffde85b200, scope=1, self=6) at eval.c:6227
#6 0x000000000042082c in vafuncall (recv=140101930878280, mid=10233, n=1, ar=0x7fffde85b2a0) at eval.c:6310
#7 0x000000000042091b in rb_funcall (recv=140101930878280, mid=10233, n=1) at eval.c:6327
#8 0x00007f6c03469625 in attribute_p (self=140101930878280, name=0x25759d0 "body") at ../../../../ext/tracemonkey/js_land_proxy.cc:142
#9 0x00007f6c0346a7e5 in respond_to_p (js_context=0x1e31bd0, obj=0x2b9f180, name=0x25759d0 "body") at ../../../../ext/tracemonkey/js_land_proxy.cc:191
#10 0x00007f6c0346a9e2 in resolve (js_context=0x1e31bd0, obj=0x2b9f180, id=34633700, UNUSED_flags=3, objp=0x7fffde85b558) at ../../../../ext/tracemonkey/js_land_proxy.cc:427
#11 0x00007f6c034fc3dc in js_LookupPropertyWithFlags (cx=0x1e31bd0, obj=0x2b9f180, id=34633700, flags=3, objp=0x7fffde85b650, propp=0x7fffde85b648) at jsobj.cpp:3810
#12 0x00007f6c034fe64b in js_SetPropertyHelper (cx=0x1e31bd0, obj=0x2b9f180, id=34633700, cacheResult=1, vp=0x7fffde85bb28) at jsobj.cpp:4364
#13 0x00007f6c0358d9ba in js_Interpret (cx=0x1e31bd0) at jsops.cpp:1854
#14 0x00007f6c034eddfa in js_Invoke (cx=0x1e31bd0, argc=2, vp=0x1e66e48, flags=0) at jsinterp.cpp:1414
#15 0x00007f6c034dcb62 in js_fun_call (cx=0x1e31bd0, argc=2, vp=0x1e66e10) at jsfun.cpp:1955
#16 0x00007f6c0358f53c in js_Interpret (cx=0x1e31bd0) at jsops.cpp:2208
#17 0x00007f6c034eccbf in js_Execute (cx=0x1e31bd0, chain=0x2b28ac0, script=0x1de1d70, down=0x0, flags=0, result=0x7fffde85ce30) at jsinterp.cpp:1657
#18 0x00007f6c03487608 in JS_ExecuteScript (cx=0x1e31bd0, obj=0x2b28ac0, script=0x1de1d70, rval=0x7fffde85ce30) at jsapi.cpp:4962
#19 0x00007f6c0347c82c in evaluate_compiled_script (self=140101932687920, compiled_script=140101932045480, ruby_scope=140101931198560) at ../../../../ext/tracemonkey/runtime.cc:239

I don't feel very confident I know the best way to fix this. I understand what's going on in broad strokes, but I don't think I have the subtleties down. Plus I can see multiple places to put the protect and I'm not sure the cleanest.

#resolve is the only thing I see calling respond_to_p but I see #get and #set calling the other predicates so I wonder if they are vulnerable to exceptions on the ruby side? I was also wondering about the report_ruby_error_in_js call in call_ruby_from_js_va.


Reply all
Reply to author
Forward
0 new messages