Hi Jose, I tried to get my local llvm install again to a point where I can see backtrace information, but still failed to get valgrind/massif to print these nice backtraces. All of the llvm addresses are not resolved so far.
But a appart from that which gl example/test program do you run to see that leakage? And additionally looking at this below backtrace snippet and analyzing the code that is called in llvm: On Wednesday, May 14, 2014 02:45:26 you wrote: > The problem is that when I do this, memory starts leaking for every > compilation (even with LLVM 3.4): > > -> 100.00% (672B): operator new(unsigned long) > -> 100.00% (672B): std::_Rb_tree<llvm::EVT, llvm::EVT, > std::_Identity<llvm::EVT>, llvm::EVT::compareRawBits, > std::allocator<llvm::EVT> >::_M_insert_unique(llvm::EVT const&) > -> 100.00% (672B): llvm::SDNode::getValueTypeList(llvm::EVT) > -> 100.00% (672B): llvm::SelectionDAG::getVTList(llvm::EVT) Ok, I see, this std::set in ./lib/CodeGen/SelectionDAG/SelectionDAG.cpp holds EVT instances which have a possible pointer to llvm::Type objects declared in llvm/IR/Type.h. And such a Type seems to reference a LLVMContext with the 'Context' member in llvm::Type. Since the std::set<EVT, ...>'s less operator treats EVT's to equivalent EVT's referencing llvm::Types originating from different LLVMContext instances differently, this grows with the LLVMContext instances around. Ok, a correct solution inside llvm would be to prune these set entries once the LLVMContext dies. A workaround from our side could probably be to have a LLVMContext private to the GL context as already suggested. That would still grow with the number of GL contexts. But that is a way more unlikely use pattern for an application to create magnitudes of GL contexts. Well it is still a possible scenario, but willing to beat on a GL stack with threads is also a possible scenario ... I have not yet tried something, since I am not yet able to reproduce, but thoughts?? Greetings Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
