Assertion failure: operationLimit <= JS_MAX_OPERATION_LIMIT, at /builds/moz2_slave/mozilla-central-macosx-debug/build/js/src/jsapi.cpp:5272 I hit this when I merged to m-c on the leak test box.
js_InitOperationLimit sets this to JS_MAX_OPERATION_LIMIT + 1, which makes this look wrong: > JS_SetOperationLimit(cx, JS_GetOperationLimit(origCx));
I wallpapered this for now: http://hg.mozilla.org/mozilla-central/rev/562d8990f33a
Created attachment 357150 [details] [diff] [review] fix v1 My patch for the bug 472702 initializes JSContext.operationLimit to JS_MAX_OPERATION_LIMIT + 1 to detect if the embedding was ever set operation limit for JSContext instance explicitly. This is used by jstracer.cpp not to generate the code to update JSContext.operationCount when the limit is not set assuming that an application will use a separated thread or signals to set JSContext.operationCount to 0. But I forgot in JS_GetOperationLimit to return JS_MAX_OPERATION_LIMIT, not JS_MAX_OPERATION_LIMIT + 1, so application can freely continue to use JS_(Get|Set)OperationLimit without surprises.
Attachment #357150 - Flags: review?(mrbkap)
Comment on attachment 357150 [details] [diff] [review] fix v1 Don't forget to back out sayrer's wallpaper from comment 2 out when you check this in! Thanks.
Attachment #357150 - Flags: review?(mrbkap) → review+
landed to tm - http://hg.mozilla.org/tracemonkey/rev/293624178003
(In reply to comment #5) > (From update of attachment 357150 [details] [diff] [review]) > Don't forget to back out sayrer's wallpaper from comment 2 out when you check > this in! Thanks. Done - http://hg.mozilla.org/tracemonkey/rev/90bdc10e0c83
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey → [needs 1.9.1 landing]
Whiteboard: [needs 1.9.1 landing]
You need to log in before you can comment on or make changes to this bug.