similar to: [LLVMdev] opt does not load poolalloc

On Thursday 11 June 2009 18:14:08 John Criswell wrote: > If your use of pool allocation requires that you can always get the pool > handle for a pointer, you need to make sure that pool allocation is > configured so that it doesn't generate the above scenario. I think > there is an option to make all pools be global pools. Some time ago, I used AnalysisUsage's

Torvald Riegel wrote: > On Thursday 11 June 2009 18:14:08 John Criswell wrote: > >> If your use of pool allocation requires that you can always get the pool >> handle for a pointer, you need to make sure that pool allocation is >> configured so that it doesn't generate the above scenario. I think >> there is an option to make all pools be global pools.

Patrick Alexander Simmons wrote: > Thank you, and I apologize for conflating the two passes. > > My main remaining concern is about what happens when there is a node in > a function's DSGraph that points to a pool (or pools, if there are > multiple callers) that is not in the DSGraph of that function. For > example, on page 3 of the 2005 PLDI paper, the DSGraph given for

Thank you, and I apologize for conflating the two passes. My main remaining concern is about what happens when there is a node in a function's DSGraph that points to a pool (or pools, if there are multiple callers) that is not in the DSGraph of that function. For example, on page 3 of the 2005 PLDI paper, the DSGraph given for createnode(), Data is pointing to an unlabeled node in the

VFS: brelse: Trying to free free buffer buffer layer error at fs/buffer.c:1182 Pass this trace through ksymoops for reporting Call Trace: [<c01468f0>] [<c0146aa9>] [<c0146b57>] [<c0146b84>] [<c0175a17>] [<c023cbfa>] [<c023d2f1>] [<c0175c90>] [<c01728e9>] [<c01ad7d6>] [<c014d215>] [<c0154c68>] [<c0154f79>]