Summary: | Memory is written to after deallocated, in GraphicsLayer::setMaskLayer. | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | peavo | ||||
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | alex.christensen, bfulgham, commit-queue, esprehn+autocc, glenn, kondapallykalyan, simon.fraser | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
peavo
2015-02-02 12:35:34 PST
Created attachment 245894 [details]
Patch
Comment on attachment 245894 [details]
Patch
Wow! That's not good! :-)
I guess this happens if the m_childClippingMaskLayer is also part of the layer hierarchy and is therefore accessed for a "setMaskLayer" update?
This might only happen in the WinCairo implementation due to its use of the texture mapping stuff to handle accelerated compositing.
r=me.
(In reply to comment #2) > Comment on attachment 245894 [details] > Patch > Thanks for reviewing :) > Wow! That's not good! :-) > > I guess this happens if the m_childClippingMaskLayer is also part of the > layer hierarchy and is therefore accessed for a "setMaskLayer" update? > > This might only happen in the WinCairo implementation due to its use of the > texture mapping stuff to handle accelerated compositing. > Good point, could be a bug only on WinCairo. Also, it was not really harmful, since the overwrite happened just after deallocation, and nobody had reallocated the block, yet ... :) > r=me. Comment on attachment 245894 [details] Patch Clearing flags on attachment: 245894 Committed r179495: <http://trac.webkit.org/changeset/179495> All reviewed patches have been landed. Closing bug. |