Closed
Bug 458288
Opened 16 years ago
Closed 16 years ago
TM: Heap corruption with gczeal, yield
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: gal)
Details
(Keywords: crash, testcase, Whiteboard: [sg:critical])
Attachments
(4 files, 1 obsolete file)
$ ~/tracemonkey/js/src/Darwin_DBG.OBJ/js -j a5.js
js(40337) malloc: *** error for object 0x302f90: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Crash [@ szone_free] attempting to access 0xfffff804
$ valgrind ~/tracemonkey/js/src/Darwin_DBG.OBJ/js -j a5.js
Invalid write of size 4 at nanojit::Fragment::blacklist
Address was freed during GC js_FlushJITCache
Reporter | ||
Comment 1•16 years ago
|
||
14 invalid reads, 2 invalid writes.
Reporter | ||
Updated•16 years ago
|
Whiteboard: [sg:critical]
Reporter | ||
Comment 2•16 years ago
|
||
Still happens on tracemonkey branch after nanojit2 landing.
![]() |
||
Updated•16 years ago
|
Assignee: general → danderson
If js_Interpret sees that the JIT cache was flushed, it sets a "safe delete" flag in addition to the deep abort flag, which causes it to not read from its fragment.
Attachment #344384 -
Flags: review?(brendan)
(Whoops, ignore that erroneous "pendingFlush")
Comment 5•16 years ago
|
||
Comment on attachment 344384 [details] [diff] [review]
proposed fix
>diff -r 35c34996d80e js/src/jscntxt.h
>--- a/js/src/jscntxt.h Tue Oct 21 15:21:23 2008 -0700
>+++ b/js/src/jscntxt.h Wed Oct 22 15:30:57 2008 -0700
>@@ -141,6 +141,8 @@ typedef struct JSTraceMonitor {
> JSFragmentCacheEntry fcache[JS_FRAGMENT_CACHE_SIZE];
> jsval *recoveryDoublePool;
> jsval *recoveryDoublePoolPtr;
>+ uint32 cacheId;
>+ JSBool pendingFlush;
Deadwood as noted.
>+ uint32 traceMonCacheId = JS_TRACE_MONITOR(cx).cacheId;
Suggest jitCacheId as name (to match js_FlushJITCache).
>+ if (fragment->root == fragment
isRootFragment should be equivalent and faster to test?
>+ if (f == NULL) {
Nit: !f as noted.
>+ tm->cacheId++;
cacheId is a fine name, some slight pref for cacheGen (generation) to match other generation-number-based cache flushing in SpiderMonkey.
r=me with above addressed.
/be
Attachment #344384 -
Flags: review?(brendan) → review+
Pushed changeset: http://hg.mozilla.org/tracemonkey/rev/dcf3b1f789e8
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•16 years ago
|
||
Assignee: danderson → gal
Attachment #344384 -
Attachment is obsolete: true
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•16 years ago
|
Attachment #345187 -
Flags: review?(danderson)
Assignee | ||
Updated•16 years ago
|
Attachment #345187 -
Flags: review?(brendan)
Comment 8•16 years ago
|
||
Comment on attachment 345187 [details] [diff] [review]
improved patch
Easy come, easy go! Srsly, do we have a test for the bug that was fixed by the jitCacheGen patch?
/be
Attachment #345187 -
Flags: review?(brendan) → review+
![]() |
||
Updated•16 years ago
|
Attachment #345187 -
Flags: review?(danderson) → review+
Assignee | ||
Comment 9•16 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Comment 10•16 years ago
|
||
Updated•16 years ago
|
Flags: in-testsuite+
Flags: in-litmus-
Comment 12•15 years ago
|
||
when this bug is opened, the test should be checked in.
Flags: in-testsuite+ → in-testsuite?
Updated•10 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•