[llvm] r223858 - IR: Fix memory corruption in MDNode new/delete

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Dec 9 17:40:10 PST 2014


> On 2014 Dec 9, at 17:38, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Dec 9, 2014 at 5:33 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
> > On 2014 Dec 9, at 17:31, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Tue, Dec 9, 2014 at 3:56 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> > Author: dexonsmith
> > Date: Tue Dec  9 17:56:39 2014
> > New Revision: 223858
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=223858&view=rev
> > Log:
> > IR: Fix memory corruption in MDNode new/delete
> >
> > There were two major problems with `MDNode` memory management.
> >
> >  1. `MDNode::operator new()` called a placement array constructor for
> >     `MDOperand`.  What?  Each operand needs to be placed individually.
> >
> > Why do they need to be placed individually?
> >
> 
> I'm not sure, but I think the implementation is allowed to place a cookie
> with the size.
> 
> Pretty sure that's not the case - how would user code know how big to make the buffer if that were the case?
> 
> But I could be wrong.
>  
> If you think I'm wrong, maybe problem #2 was the only real problem?
> 
> I guess so - though I haven't looked to see what important things the dtor is doing,

*IF* the Metadata that the operand points to supports RAUW, then
the operand is registered with it to be updated when it changes.

The destructor unregisters the operand.

> so I don't really know what badness could occur by not calling it.
> 
> - David




More information about the llvm-commits mailing list