Summary: | Accessibility tests crashing in BasicRawSentinelNode code | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | barraclough, fpizlo, ggaren, oliver, webkit.review.bot | ||||||
Priority: | P1 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Alexey Proskuryakov
2011-09-06 15:59:19 PDT
Yup, that's my fault. CodeBlock is assuming that it won't be destroyed until after any CodeBlocks that have calls into it are destroyed, which is a demonstrably wrong assumption. This bug will manifest itself if you have two CodeBlocks, A and B, where A contains a call to code owned by B. Then the GC decides to first destroy B and then destroy A. This can happen if both A and B became unreachable at the same time, if the heap is being destroyed, or if we call recompileAllJSFunctions(). At this stage A has a node on a linked list owned by B. Thus A likely has multiple pointers into memory that will be destroyed when B's destructor runs. Then the following dangerous and unpredictable course of events unfolds: 1) B gets destroyed, but does not remove A's node from its linked list. 2) A gets destroyed, and decides to be a good citizen and remove its node from B's linked list. Linked list removal requires accessing B's linked list, which no longer exists. Some manner of memory corruption ensues. This bug occurs because of a misguided optimization on my part. CodeBlock::~CodeBlock should ensure that any incoming calls (CallLinkInfos) that are on this's linked list are removed form the linked list and are marked as having been removed, so that when those CodeBlock's destructors run, they don't try to access garbage memory. For some reason I had convinced myself that this was unnecessary and removed it. The fix is to bring this back. I'm rolling a patch for this now. Created attachment 106511 [details]
proposed patch
Still testing this but it's ready for review.
Created attachment 106515 [details]
the patch - fixed comment to more accurately reflect the change
Comment on attachment 106515 [details]
the patch - fixed comment to more accurately reflect the change
This appears to fix the problem. I cannot get crashes anymore, and nothing else seems to have regressed.
Comment on attachment 106515 [details]
the patch - fixed comment to more accurately reflect the change
r=me
Comment on attachment 106515 [details] the patch - fixed comment to more accurately reflect the change Clearing flags on attachment: 106515 Committed r94623: <http://trac.webkit.org/changeset/94623> All reviewed patches have been landed. Closing bug. |