| Summary: | Need to detail the message: Mismatched free() / delete / delete [] | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Yuri <yuri> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | flo2030, pjfloyd, tom |
| Priority: | NOR | ||
| Version First Reported In: | 3.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
I got the message on Ubuntu/i386 Does the problem occur with the latest release 3.6.1? Did you check that the problem is not in the FreeBSD port? For us to investigate it needs to be reproducible on Linux. You need to provide instructions for how to do that. If you're running stock llvm: what revision / release number is it? What is the command line? What are the input files etc. You've set the OS on this report to "FreeBSD" but then in the second comment you say it is "Ubuntu/i386" so which is it? Mentioned in subject mismatch message can be found in the upstream. I checked, it's not in FreeBSD port source. Therefore, it's a general problem on most/all OSes. Linux has it. We know the message is there, but you are claiming (as I understand it) to have some code which is valid but which triggers that message. What we want to know is what platform you reproduced that problem on. The message itself is fine, and when issued indicates a real problem. The question is whether there is a false positive scenario. What I was trying to say, that the code in question looks clean, and message from valgrind is too vague and doesn't help to localize the issue. Once you fix the message, so that it will tell exactly what is not balanced, I can retest the code in question and determine more easy is it really a code isue or not. So this PR (267176) is solely about the vagueness of the aforementioned message. The problem is that it's a lot of work to do what you are suggesting - we would separate our what is currently a single error type into about nine different types so that there was one for each combination. The type of mismatch should be obvious from the error message anyway. You have quoted the bit which shows that the free was a non-array delete, and below that (but not quoted by you) should be a stack trace showing where the memory was allocated which should tell you the allocation type. This is the llvm compiler library code that causes such error. They have custom c++ allocators defined. This may be that some object is allocated through allocators and freed as different type maybe using 'delete' of some other class. It's not obvious unless you are an author or owner of the code. And valgrind doesn't help in such case. As I explained, valgrind should be showing you a stack trace for both the allocation and deallaction sites which should make it clear what the error is. If it's not doing that then please say so. Alternatively please post the whole output of valgrind here so that we can see properly what is going on. I don't think that it is worth considering changing this. It would affect too many users for little or no benefit. |
I am getting this message on the code using the current llvm like the one below. --- memcheck message --- ==24227== Mismatched free() / delete / delete [] ==24227== at 0x4025504: operator delete(void*) (vg_replace_malloc.c:387) ==24227== by 0x9C69C09: llvm::BasicBlock::~BasicBlock() (BasicBlock.cpp:83) ==24227== by 0x9C6B509: llvm::ilist_node_traits<llvm::BasicBlock>::deleteNode(llvm::BasicBlock*) (in /usr/local/llvm/svn-r126022.dbg/lib/libLLVM-2.9svn.so) ==24227== by 0x9C6B103: llvm::iplist<llvm::BasicBlock, llvm::ilist_traits<llvm::BasicBlock> >::erase(llvm::ilist_iterator<llvm::BasicBlock>) (ilist.h:463) ==24227== by 0x9C69D1E: llvm::BasicBlock::eraseFromParent() (BasicBlock.cpp:101) ==24227== by 0x9CB6940: llvm::Function::dropAllReferences() (Function.cpp:233) ==24227== by 0x9D23754: llvm::Module::dropAllReferences() (Module.cpp:449) ==24227== by 0x9D225E9: llvm::Module::~Module() (Module.cpp:70) Corresponding LLVM code is quite plain: class BasicBlock : public Value, // Basic blocks are data objects also public ilist_node<BasicBlock> { ... explicit BasicBlock(LLVMContext &C, const Twine &Name = "", Function *Parent = 0, BasicBlock *InsertBefore = 0); ... ~BasicBlock(); }; No operator new with non-standard allocation. The message 'Mismatched free() / delete / delete []' should explain how it is mismatched. And in the situation I describe here I can't find an explanation what has happened wrong. I think this is a bug in valgrind.