Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Memory corruption #1701

Closed
llvmbot opened this issue Apr 14, 2007 · 8 comments
Closed

Memory corruption #1701

llvmbot opened this issue Apr 14, 2007 · 8 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Apr 14, 2007

Bugzilla Link 1329
Resolution FIXED
Resolved on Feb 22, 2010 12:51
Version trunk
OS Windows XP
Attachments Bytecode file that causes memory corruption in opt
Reporter LLVM Bugzilla Contributor
CC @asl

Extended Description

While trying to debug a different problem using Visual Studio, I encountered a
memory corruption that appears to go unnoticed on Unix:

Debug Assertion Failed!

Program: c:\llvm\win32\debug\opt.exe
File: dbgdel.cpp
Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

and the stack trace is:

 msvcr71d.dll!operator delete(void * pUserData=0x0012f100)  Line 52 + 0x51

C++
msvcr71d.dll!operator delete[](void * p=0x0012f100) Line 21 + 0x9 C++
opt.exe!llvm::SmallPtrSetImpl::~SmallPtrSetImpl() Line 69 + 0x17 C++
opt.exe!llvm::SmallPtrSet<llvm::Instruction
*,16>::~SmallPtrSet<llvm::Instruction *,16>() + 0x2b C++
opt.exe!llvm::SmallSet<llvm::Instruction *,16>::~SmallSet<llvm::Instruction
*,16>() + 0x2b C++
opt.exe!llvm::SetVector<llvm::Instruction *,std::vector<llvm::Instruction
*,std::allocator<llvm::Instruction *> >,llvm::SmallSet<llvm::Instruction *,16>

::~SetVector<llvm::Instruction *,std::vector<llvm::Instruction
*,std::allocator<llvm::Instruction *> >,llvm::SmallSet<llvm::Instruction *,16>
() + 0x59 C++
opt.exe!anonymous namespace'::LCSSA::visitSubloop(llvm::Loop * L=0x00f18350) Line 118 + 0x19 C++ opt.exe!anonymous namespace'::LCSSA::runOnFunction(llvm::Function &
F={...}) Line 97 + 0x17 C++
opt.exe!llvm::FPPassManager::runOnFunction(llvm::Function & F={...}) Line
1074 + 0x15 C++
opt.exe!CGPassManager::runOnModule(llvm::Module & M={...}) Line 109 + 0x16
C++
opt.exe!llvm::MPPassManager::runOnModule(llvm::Module & M={...}) Line 1142

  • 0x15 C++
    opt.exe!llvm::PassManagerImpl::run(llvm::Module & M={...}) Line 1174 +
    0x10 C++
    opt.exe!llvm::PassManager::run(llvm::Module & M={...}) Line 1207 C++
    opt.exe!main(int argc=6, char * * argv=0x00325cb8) Line 358 C++
    opt.exe!mainCRTStartup() Line 398 + 0x11 C
    kernel32.dll!7c816fd7()
    ntdll.dll!7c915b4f()

The command to reproduce with the attached bytecode file is:

opt -std-compile-opts Output/primes.linked.rbc -o Output/primes.linked.bc -f
@asl
Copy link
Collaborator

asl commented Apr 14, 2007

Valgrind is silent here. Miscompilation?

@asl
Copy link
Collaborator

asl commented Apr 14, 2007

Hmmm. Interesting. Release build is valgrind-clean. But Debug - not:

==29944== Invalid read of size 4
==29944== at 0x8388D9E: llvm::GlobalVariable::getNext() (GlobalVariable.h:99)
==29944== by 0x8388D94: llvm::SymbolTableListTraits<llvm::GlobalVariable,
llvm::Module, llvm::Module, llvm::ilist_traitsllvm::GlobalVariable

::getNext(llvm::GlobalVariable*) (SymbolTableListTraits.h:54)
==29944== by 0x8388760:
llvm::ilist_iteratorllvm::GlobalVariable::operator++() (ilist:141)
==29944== by 0x83882EC: (anonymous
namespace)::ConstantMerge::runOnModule(llvm::Module&) (ConstantMerge.cpp:63)
==29944== by 0x85A09C1: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1142)
==29944== by 0x85A0B87: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1174)
==29944== by 0x85A0CF3: llvm::PassManager::run(llvm::Module&)
(PassManager.cpp:1206)
==29944== by 0x837099C: main (opt.cpp:356)
==29944== Address 0x42BC524 is 52 bytes inside a block of size 76 free'd
==29944== at 0x402167A: operator delete(void*) (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==29944== by 0x857C880: llvm::GlobalVariable::~GlobalVariable() (Module.h:39)
==29944== by 0x8388B86: llvm::iplist<llvm::GlobalVariable,
llvm::ilist_traitsllvm::GlobalVariable
::erase(llvm::ilist_iteratorllvm::GlobalVariable) (ilist:323)
==29944== by 0x857C641: llvm::GlobalVariable::eraseFromParent() (Globals.cpp:137)
==29944== by 0x8388130: (anonymous
namespace)::ConstantMerge::runOnModule(llvm::Module&) (ConstantMerge.cpp:68)
==29944== by 0x85A09C1: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1142)
==29944== by 0x85A0B87: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1174)
==29944== by 0x85A0CF3: llvm::PassManager::run(llvm::Module&)
(PassManager.cpp:1206)
==29944== by 0x837099C: main (opt.cpp:356)

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 14, 2007

I will continue to investigate with Visual Studio. It has some powerful
debugging memory debugging aids I haven't brought to bear yet.

@lattner
Copy link
Collaborator

lattner commented Apr 14, 2007

akor, does your run include this patch?
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047522.html

@lattner
Copy link
Collaborator

lattner commented Apr 14, 2007

Thanks for digging in Jeff!

@asl
Copy link
Collaborator

asl commented Apr 14, 2007

Well. Seems it wasn't. TOT is valgrind-clean for me.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 14, 2007

Found it. SmallPtrSetImpl lacks a copy constructor. The default constructor
simply copies CurArray, which magically turns a small array into a non-small
array, eventually causing a bogus deletion. Will have a fix shortly.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 14, 2007

Fixed:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047538.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070409/047539.html

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@asl @lattner @llvmbot