similar to: Heap problems with 3.8.0rc2 in combination with vs2015 sp1

I downloaded 3.8.0rc3 and I also have it in 3.8.0rc3. I did set a data access breakpoint on the first function ptr that causes the invalid heap. This would allow me to break whenever someone is touching that address. It did not show double deletes during debugging. Further more I managed to narrow it down to 2 function calls: // stupid code, but its just for triggering heap error auto func =

I made the llvm::Function() constructor public (for testing purpose) and used the non-overloaded new. auto func = ::new llvm::Function(...) if (func) func->eraseFromParent(); And the heap corruption is gone! Did something changed in llvm::User::new between 3.7.1 and 3.8.0 ? I found a bug in llvm ? On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I

I found the root cause, but I don't know what's the best approach to fix it. Under windows, 64 bit, when a function is created the void *User::operator new(size_t Size) operator allocates space + Use*. In the Use* the HasHungOffUses is set to true. So the ptr to the use* is returned as new object. This ptr is NOT the ptr that was allocated by the system. For that ptr you need ptr - word

Turns out llvm initializes memory before the constructor is invoked. Visual studio has /sdl by default on, and the __autoclassinit2 will zero the memory before the constructor is reached causing all the setters to be default zero. which clears the hashungoff var and causing the delete to flow in wrong part. When /sdl is enabled, the compiler generates code to perform these checks at run time: —

Dear sir, Thanks for your reply. I apologize for taking a few days to reply. > Crashed how? Please see the below. > Have you turned on ASan? Not yet, but thanks for the suggestion. I guess I will try to rebuild my modified Clang+LLVM with addr. san. and see what happens. > I recommend attaching a minimal reproduction... Well, since I`m hacking on LLVM itself, this is not

Dear all, In the process of trying to add optimization for better layout of global variables, I have run up against a roadblock: I don`t seem to be able to sort the contents of a "SymbolTableListTraits<GlobalVariable>" -- or even swap two elements in that list -- without causing LLVM to crash. I have tried writing a comparator class and then using "llvm::iplist<

Hi, Thank Brian Gaeke so much. Following TraceBasicBlocks.cpp, I modified the code as below and could insert instruction or function I need into anywhere in Module. But it works well without BB->getInstList().push_back(InstrCall), and if I add the BB->getInstList().push_back() following new CallInst(), I got error information when runing opt. What is the reason for it? And is it necessary

Hi, Thanks both of you for the help. I just missed that Create function had many optional arguments... sorry for that. However my problem wasn't coming from here (IRBuilder CreateCall function still return a pointer to CallInst so I just added 2 times the call?). I didn't wanted to detail the all issue previously because I knew I had a problem with my syntax. So here's my problem: I

I am confused by GlobalVariable::eraseFromParent's declaration: /// This method unlinks 'this' from the containing module and deletes it. void eraseFromParent(); In Globals.cpp the unlinking is done and SymbolTableListTraits cleans up the symbol table but I don't see anything that actually deletes the object. Is the comment misleading or am I missing something?

Op 20-3-2018 om 12:40 schreef Evgeny Leviant: > This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction > in @_island_debug_invoke and many other functions. The code expects either pointer to a filter > function or null in first operand, while you're passing pointer to structure: > > catchpad within %80 [{i8*, i8*}* anon..., ...] > >

This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction in @_island_debug_invoke and many other functions. The code expects either pointer to a filter function or null in first operand, while you're passing pointer to structure: catchpad within %80 [{i8*, i8*}* anon..., ...] ________________________________________ От: Carlo Kok <ck at

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >

Hey everyone, So I have an LLVM pass that appears to run completely and work fine, and then it aborts at the very end. When exiting the final runOnFunction call, I get the following error / stack dump. I cannot figure out why this is happening for the life of me - does anyone have any ideas? I'm not trying to do any crazy deallocation or anything, it just seems like a normal pass to me.

Hi Griffin, did your pass create a data structure that holds values somehow, and forgot to delete it? Also, try running under valgrind in case this is due to a memory error of some kind. Ciao, Duncan. > So I have an LLVM pass that appears to run completely and work fine, and > then it aborts at the very end. When exiting the final runOnFunction call, > I get the following error /

Hi Has anybody tell me how to create some new type qualifies in LVM? A type qualify, like "const" in C, is useful for program analysis. I hope that I can set/get the type qualify of any value in a program analysed. Or, if I could add a property to the value class and set/get the property, it is same to add some new type qualifies. So, I simply insert a "int" private

Using Valgrind hasn't shown me anything terribly unusual. And I'm confused because its not even trying to delete a real instruction; deleting a void type with no name? That doesn't make any sense... Any other hints? I've seen a few posts in the past about this relating to some internal LLVM bugs... -Griffin On Thu, 12 Jan 2012 21:26:41 +0100, Duncan Sands <baldrick at

+llvm-dev > On 2016-Feb-09, at 12:54, Harris, Kevin <Kevin.Harris at unisys.com> wrote: > > Duncan, > Kevin Harris here, from Unisys. In our application, generating LLVM IR, we have several instances of code that looks like this: > > . . . > Value* pDS; > . . . > auto argIt = pFunc->arg_begin(); >

Hello, I've been stuck with a problem for about a month, and it has stumped everyone in my lab. I have a function pass that runs, and when it finishes and opt goes to return, I get: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at /x/grwright/llvm/llvm-2.9/lib/VMCore/Value.cpp:569! On a simple test case, the error becomes 'i32 %'

Xia, LLVM doesn't really use type qualifiers the way you're thinking about it. In LLVM parlance, types are neither const nor non-const, they just define the fundamental nature of a value. However, LLVM fully supports Constant Values (see include/llvm/Constant.h) and constant global variables (see include/llvm/GlobalVariable.h). You might want to read up on the LLVM IR a bit here:

On 08/04/2016 01:33 PM, David Majnemer wrote: > You should never be copying or moving around Values. Why not? Is that because of this thing you also wrote in the same message: "use lists are allocated before the object"? > An llvm::Value (which GlobalVariable is a subtype of) should exist only in the heap. Trying to sort a container of such objects doesn`t require me to