similar to: [LLVMdev] LLVM and memory leaks

I guess the issue of singleton objects leaking is not something that he LLVM team is very concerned about, since there has been no replies to my first mail... But for me it is a big problem. I can't use LLVM in our project if it triggers our leak detection system, since it will hide other problems. Since actually deleting these objects is proving difficult (types can have circular

On Thu, 11 Nov 2004, Morten Ofstad wrote: > I guess the issue of singleton objects leaking is not something that he > LLVM team is very concerned about, since there has been no replies to my > first mail... But for me it is a big problem. I can't use LLVM in our > project if it triggers our leak detection system, since it will hide > other problems. Hi Morten, I appologize for

>>Since actually deleting these objects is proving difficult (types can >>have circular references, so you have to deal with things getting >>deleted while there are still references to them), I propose to >>introduce a new class SingletonPool to lib/Support which keeps all the >>singleton instances and can be free'd without actually calling the

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons

Hi, here are some minor patches that for various reasons I've not submitted yet - I'm just trying to clear my list of differences before christmas... First of all the clear.patch file contains a patch that enables the JIT to drop all global mappings. I need this because when I have N threads I compile N different versions of my functions using different memory areas for global

Hi, I finally took the time to track down the remaining memory leaks beside the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It turns out almost all of them came from the command line options module, so I cleaned up the patch for LeakDetector and made a new patch for CommandLine. The patches are attached to this message. That got rid of all but 4 leaks I'm getting,

Although most of the leaks I detected in LLVM were from singleton objects, there also seem to be some real leaks. One such leak (which is creating problems for me when I try to get rid of the constant singletons) seems to be a GlobalVariable created on line 145 of Transforms/Scalar/lowerInvoke.cpp -- any suggestions how I can make sure this GlobalVariable gets deleted? Actually I'm a bit

On Thu, 11 Nov 2004, Morten Ofstad wrote: > Well, I already tried that, but the destructors crash because they are > referencing other things which are being destroyed - Constants are Users > of each other and there is no easy way to destroy them in the right > order. There are ways around this, but it turns into a two-pass operation: loop over all constants to drop their uses, then

Chris Lattner wrote: >>It would also solve another problem -- We generate new shader code when >>the user changes parameters, because the shader will be executed >>millions of times it makes sense to recompile it with changed constants >>to get maximum optimization. But if some of these parameters are floats, >>and there is no way to destroy constants in LLVM we have

Dear all, I have wrapped a C++ function in an R package. I allocate/deallocate memory using C++ 'new' and 'delete'. In order to allow user interrupts without memory leaks I've moved all the delete statements required after an interrupt to a separate C++ function freeMemory(), which is called using on.exit() just before the .C() call. I am concerned about the

I have some patches of my own: * An improvement on Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet),

On Mon, 15 Nov 2004, Morten Ofstad wrote: > > If this is a serious issue, it would be straight-forward to add a global > > function to flush out unused constants. I would be happy to accept a > > patch to do that. > > Here is an implementation of this -- there are some things you might not > like about it: > > 1) I had to make the private destroyConstantImpl

These type of constructs are less than ideal if you have something that uses LLVM as a library in a "long running" application (e.g. imagine something like photo editor that compiles "filters", and a user that loads the application on monday, and closes it on the following thursday) , as there is no (trivial) way to know that this stringmap exists, or that it may need cleaning

On Fri, 19 Nov 2004, Morten Ofstad wrote: > I finally took the time to track down the remaining memory leaks beside > the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It > turns out almost all of them came from the command line options module, > so I cleaned up the patch for LeakDetector and made a new patch for > CommandLine. The patches are attached to this

Chris Lattner wrote: > On Mon, 6 Dec 2004, Morten Ofstad wrote: >> I guess what I'd like to know is if the process of spilling constants >> to memory could be a bit more controlled, maybe using the JIT memory >> manager and putting it in with the function stubs? > > Yes, this can and should definitely be improved. If you look at >

On Mon, 13 Dec 2004, Morten Ofstad wrote: > I have made a patch along these lines. Although I reused the JITMemoryManager > object, I am allocating constant pools from another block of memory. This > fixes my remaining leaks. It would be nice if also the global variables were > allocated in this way, but it's not needed for my application since I'm > managing that memory

On Tuesday, 27 June 2017 13:55:57 CEST Richard W.M. Jones wrote: > We permit the following constructs in libguestfs code: > > if (guestfs_some_call (g) == -1) { > fprintf (stderr, "failed: error is %s\n", guestfs_last_error (g)); > } > > and: > > guestfs_push_error_handler (g, NULL, NULL); > guestfs_some_call (g); >

Chris Lattner wrote: > On Mon, 13 Dec 2004, Morten Ofstad wrote: > >> I have made a patch along these lines. Although I reused the >> JITMemoryManager object, I am allocating constant pools from another >> block of memory. This fixes my remaining leaks. It would be nice if >> also the global variables were allocated in this way, but it's not >> needed

>>I've also determined why VC++ complains about deprecated destructors >>when using hash_map. Because it's not ANSI (yet), Microsoft decided to >>move it from the std namespace to the stdext namespace. Use of >>std::hash_map is therefore deprecated. Similar shenanigans have been >>committed by gcc from one version to another. I see where this is

Hi, I'm currently trying to find and fix memory leaks (compiling with ``-fsanitize=address``) in the KLEE tool [1] an having found some leaks and I'm having trouble suppressing them. I'm trying to suppress them using the ``-fsanitize-blacklist=blacklist.txt`` option as documented at [2]. I'm using Clang 3.7 ( Arch Linux package 3.7.0-6). The sort of reported leaks I see are ```