similar to: [LLVMdev] Memory Leaks

Chris, I'm using a llvm_shutdown_obj object and it calls llvm_shutdown when I delete it. Do I need to call llvm_shutdown() again afterwards? It looks to me like the static object is being created after my program exits main(). From: Chris Lattner [mailto:clattner at apple.com] Sent: Friday, January 13, 2012 10:11 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev]

On Wed, Dec 25, 2013 at 9:38 PM, dblaikie at gmail.com <dblaikie at gmail.com> wrote: > Its generally been by design that tblgen leaks. Might be nice to fix one day > but it's been that way for a while now so don't expect it to be fixed soon. > > If thats the suppression mechanism of choice (I would've expected a build > flag option) for lsan, I'd say go for

On Jan 13, 2012, at 10:08 AM, Villmow, Micah wrote: > > Are these known issues? If so, how do I free this memory? > Hi Micah, Please try calling llvm_shutdown() -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120113/a51dc89c/attachment.html>

Also, this can be easily reproduced with the following command: valgrind --tool=memcheck --show-reachable=yes --leak-check=full --track-origins=yes --leak-check=full opt -disable-opt -O0 <some random bitcode file> Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Friday, January 13, 2012 10:23 AM To: Chris Lattner Cc: LLVM

LGTM. I think it is totally reasonable to just disable LSan directly in tablegen at least for now. I would leave some comments on the disabling to clarify: 1) What it does, the reader may not have heard about LSan. 2) Some of the high-level information from this thread as pointers for anyone who wants to go and fix this some day. -Chandler On Wed, Dec 25, 2013 at 2:26 PM, Kostya Serebryany

Are you calling llvm_shutdown() at the end of your program? You should. valgrind reports "possible" leaks when it finds a pointer pointing inside a memory block (as opposed to at the first byte), and LLVM uses those a lot. llvm_shutdown() will free a lot of that memory, including the LLVMContext, which should remove any false leaks you might be seeing. On the other hand, the

Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps

Hi, I am working on a binary translator and use LLVM for this. In the process, I generate millions of constants (immediate values in the source binary code). The problem is that these constants seem to be not cleaned when I delete the LLVM code (using Function::deleteBody() ) and as a result the memory usage keeps growing. I browsed the forum and found that constants "live forever" by

There may be another explanation, but I've seen this sort of issues before: LLVM uses several object pools (associated w/ LLVM context and JIT engine), and often objects from these pools are leaked, or the pools grow infinitely due to implementation bugs. These are not an ordinary memory leaks, as destroying the LLVM context and/or JIT engine will successfully reclaim all the memory. The

Hi Vitaly C. wrote: > > Is there are simple way of cleaning the used memory without destroying > everything (unloading the ExecutionEngine, freeing the module, calling > llvm_shutdown) ? Ideally I would like something which brings everything to > the state just after I created the JIT engine for the first time. > I've tried to run the Fibonacci example with Valgrind

I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()

I'm curious about the design rationale for how ManagedStatic instances are cleaned up, and I'm hoping someone can shed some light on it. Currently, ManagedStatic objects are cleaned up when llvm_shutdown() traverses the global list of initialized objects and calls destroy() on each. This leads to two questions: 1. An assertion enforces that the objects are deleted in reverse order of

Hi, We are trying to enable LeakSanitizer on our asan/msan llvm bootstrap bot (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/). In clang itself there are two leaks (http://llvm.org/bugs/show_bug.cgi?id=18318, http://llvm-reviews.chandlerc.com/D2472) and one lsan-hostile feature (http://llvm.org/bugs/show_bug.cgi?id=18320), all of which are easy to fix. And there are also

Hi, I'm testing how to free memory of a JIT'd function. I thought ExecutionEngine::freeMachineCodeForFunction() and Function::eraseFromParent() would work and did a test with the following sample code. But I found that the memory usage of the process is constantly growing as the while loop goes. Could someone shed light on this please? Here is the code. int main(int argc, char **argv) {

Hi llvmdev! In our project (Windows, Visual Studio compiler) we've got some frontend which generates LLVM IR. Now I'm observing strange *llvm_shutdown* behavior. If I called it when I was done using the LLVM APIs I saw that destructors of static objects created new ManagedStatic objects, which was never freed. Then I tried to use static global llvm_shutdown_obj to cause destruction

Hi, I put the sample code and a brief analysis using Valgrind to GitHub in order to make my problem clear. https://github.com/naosuke/how-to-free-memory-of-JIT-function The Valgrind heap profiler indicates memory leaking but I don't get what is wrong with the way to free memory. If someone could please offer some advice/suggestion on this, I would really appreciate it. Best, Naosuke On

Hello List, I have a question about dovecot-1.1.0-beta3 but first I'll ramble a little bit: Recently I upgraded a 0.99 installation of dovecot to 1.0.5. All went relatively smoothly until the dovecot-auth process began returning "out of memory" after a day. There is a rather large user base here. The current setup is using passdb pam with blocking=yes, with pam_ldap.so handling

Chris Lattner wrote: > On Mon, 31 Mar 2008, Jon Sargeant wrote: >> I'm attaching another round of changes. Please verify that they are correct. > > Applied with edits: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html > > I figured out what your patches don't apply. Something (your web browser, > editor, etc) is stripping

>> Can LLVM generate debugging information for a Windows target? > Yes. LLVM generates DWARF debugging information. I haven't checked its > status recently, but it worked some time ago (on mingw32). Note that, > however, you cannot mix stabs debug format and DWARF (I saw, e.g. > pretty weird results from gdb in that case), that means you will need > either use new mingw32

The fptrunc instruction states "If the value cannot fit within the destination type, ty2, then the results are undefined." This is fine, but what about other floating-point operations that can overflow? For example, does 'mul double 1.0e300, 1.0e300' produce +infinity or is it undefined? I think LLVM should treat floating-point overflows consistently. On a similar note,