On TM Linux nightly Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090604 Minefield/3.6a1pre Built from http://hg.mozilla.org/tracemonkey/rev/a481f4cce93a getting several crashes with signature: @ js_GetUpvarOnTrace(JSContext*, unsigned int, unsigned int, unsigned int, double*) http://crash-stats.mozilla.com/report/index/d52241f0-b24f-4c82-b6aa-7aa2d2090604 http://crash-stats.mozilla.com/report/index/4288bc81-53f0-40a2-8e8d-89d3a2090604 http://crash-stats.mozilla.com/report/index/9c46e921-c6f9-4775-8d51-9545a2090604 http://crash-stats.mozilla.com/report/index/03a021d9-85b2-4c34-a184-8248d2090604 Not crashing when started in -safe-mode.

The biggest difference between safe mode and non safe mode is add-ons; which do you have installed?

Safe mode also disables the JIT, which means it's not surprising that this bug would go away.

(In reply to comment #1) > The biggest difference between safe mode and non safe mode is add-ons; which do > you have installed? About:Tab 0.0.36 Console² 0.3.10 DOM Inspector 2.0.3 Firebug 1.4X.0a31 Firefox Accessibility Extension 1.5.5.0 Nightly Tester Tools 2.0.2 Update Channel Selector 1.5 Weave 0.3.2 WebChunks 0.30 YSlow 2.0.0b3

(In reply to comment #2) > Safe mode also disables the JIT, which means it's not surprising that this bug > would go away. Indeed, disabling content JIT prevents the crashes.

Same crashes occur with all extensions disabled: http://crash-stats.mozilla.com/report/index/4553a12a-e9ba-4231-9fe9-39e5b2090604 FWIW, OS is Ubuntu Jaunty fully updated.

All the crash reports linked in comment #0 have two stack frames without symbols, suggesting nested loops.

is there a URL that crashes? All of the stacks have obj_eval as well.

What I'm hearing is that we really need a test case here. Is there a clear path for getting one? Who is working on that?

23 tabs open, looks like following one causes the crashes: http://nadeausoftware.com/articles/2007/06/php_tip_how_decode_html_entities_web_page

Same URL ^ crashes on win/xp http://crash-stats.mozilla.com/report/pending/dc0c7b34-3e60-4785-9902-3da9d2090604 Changing OS from Linux to All. Not positive of regression range, but think it's since prior nightly...2 days at most. Sorry, no more time today to help nail it down.

doesn't crash on mac under valgrind, but I can get the stack there: Invalid read of size 8 at 0x3ADCA1: GetUpvarOnTraceTail(InterpState*, unsigned int, unsigned int, unsigned char*, double*) by 0x3ADE2E: js_GetUpvarOnTrace(JSContext*, unsigned int, unsigned int, unsigned int, double*) by 0x1F13DC04: ??? by 0xBFFFC7F7: ??? by 0x3D448C: js_MonitorLoopEdge(JSContext*, unsigned int&) by 0x2E490F: js_Interpret by 0x309946: js_Execute by 0x32A64C: obj_eval(JSContext*, JSObject*, unsigned int, long*, long*) by 0x30AF99: js_Invoke by 0x2F4FFF: js_Interpret by 0x309946: js_Execute by 0x287B40: JS_EvaluateUCScriptForPrincipals ( Address 0xbffba6b0 is not stack'd, malloc'd or (recently) free'd

this doesn't show up on the branch, and won't, assuming we don't take lambda_fc there.

I would recommend against taking tracing lambda_fc to the branch anyway, given that it was done after the betas. Is the mac valgrind warning from the URL in comment 9? It looks like it's probably a bug in the native stack walking, and presumably would not be too hard to pinpoint if that's a good test case.

(In reply to comment #13) > > Is the mac valgrind warning from the URL in comment 9? yes

Shell test case follows. Reducing further. function jQuery(a, c) { } jQuery.fn = {}; (function() { var e = ["ajaxStart","ajaxStop","ajaxComplete","ajaxError","ajaxSuccess","ajaxSend"]; for (var i = 0; i < e.length; i++) { new function() { var o = e[i]; jQuery.fn[o] = function(f) { return this.bind(o, f); } }; } })();

Wow, thanks! The shell test case results in a nativeStackFramePos of 4294934528 to be passed to js_GetUpvarOnTraceTail, which is obviously not good. Hopefully it is not too hard from here.

var v = {}; function a() { var o = 3; v.f = function() { return o; }; } for (i = 0; i < 6; i++) new a;

Argh. Hit return too early on the last one. I also meant to say much thanks to jorendorff for such an easy test case to debug and thanks to mrbkap to cluing me in on the secret extra bit. It could have been a 1-line fix, but I realized the type on the stack frame pos was technically wrong, and I decided to hit the argc bit problem with a sledgehammer.

Comment on attachment 381626 [details] [diff] [review] Patch >diff -r fb21a3a12180 js/src/jstracer.h >@@ -317,6 +322,14 @@ > * non-argument slot in the callee's native stack frame. > */ > int32 spoffset; >+ >+ // Safer accessors for argc. >+ enum { CONSTRUCTING_MASK = 0x8000 }; >+ JS_INLINE void set_argc(uint16 _argc, bool _constructing) { Functions defined in the class like this are implicitly inline, so I don't think you need JS_INLINE here. There's also a style preference here where I'd rather take (uint16 argc, bool constructing) and explicitly assign |this->aragc = argc | (constructing ? CONSTRUCTING_MASK : 0)|, but that's your call (I find leading underscores ugly). >+ JS_INLINE uint16 get_argc() const { return argc & ~CONSTRUCTING_MASK; } >+ JS_INLINE bool is_constructing() const { return (argc & CONSTRUCTING_MASK) != 0; } Ditto for the JS_INLINEs here. r=mrbkap with that addressed.

Thanks. I don't like those underscores either. Pushed to TM as 6a29797e88e7.

Mass change: adding fixed1.9.2 keyword (This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)