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.

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

Assertion failed in llvm-ld when linking a library #1806

Closed
llvmbot opened this issue May 17, 2007 · 9 comments
Closed

Assertion failed in llvm-ld when linking a library #1806

llvmbot opened this issue May 17, 2007 · 9 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:bitcode regression

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented May 17, 2007

Bugzilla Link 1434
Resolution FIXED
Resolved on Mar 06, 2010 13:59
Version trunk
OS All
Attachments test files, foo.c, libfoo.c, libfoo.a, foo.bc
Reporter LLVM Bugzilla Contributor

Extended Description

My llvm-ld crashed (assertion failure) when I tried to link a bc library.
Will attached the test files later.

What I did is:

llvm-gcc -c -O0 -emit-llvm libfoo.c -o libfoo.bc
llvm-ar cru libfoo.a libfoo.bc
llvm-ranlib libfoo.a
llvm-gcc -c -O0 -emit-llvm foo.c -o foo.bc

llvm-ld foo.bc libfoo.a -o all.bc
(and llvm-ld foo.bc -lfoo -o all.bc)

Both produce the following error:

==========================================================================
llvm-ld: /home/llvm/lib/VMCore/Value.cpp:57: virtual llvm::Value::~Value():
Assertion `use_begin() == use_end() && "Uses remain when a value is
destroyed!"' failed.
llvm-ld((anonymous namespace)::PrintStackTrace()+0x1a)[0x84e61b6]
llvm-ld((anonymous namespace)::SignalHandler(int)+0x110)[0x84e64de]
/lib/tls/libc.so.6[0x683898]
/lib/tls/libc.so.6(abort+0xe9)[0x685209]
/lib/tls/libc.so.6(__assert_fail+0x101)[0x67cd91]
llvm-ld(llvm::Value::~Value()+0x1c4)[0x84a2dd6]
llvm-ld(llvm::User::~User()+0x1b)[0x82ee97f]
llvm-ld(llvm::Constant::~Constant()+0x1b)[0x82eeab7]
llvm-ld(llvm::GlobalValue::~GlobalValue()+0x34)[0x845921e]
llvm-ld(llvm::Function::~Function()+0x9d)[0x8454cdb]
llvm-ld(llvm::iplist<llvm::Function, llvm::ilist_traitsllvm::Function

::erase(llvm::ilist_iteratorllvm::Function)+0x33)[0x8367a15]
llvm-ld(llvm::iplist<llvm::Function, llvm::ilist_traitsllvm::Function
::erase(llvm::ilist_iteratorllvm::Function,
llvm::ilist_iteratorllvm::Function)+0x21)[0x8479465]
llvm-ld(llvm::iplist<llvm::Function, llvm::ilist_traitsllvm::Function
::clear()+0x53)[0x84794e7]
llvm-ld(llvm::Module::~Module()+0x2a)[0x84785ea]
llvm-ld(std::auto_ptrllvm::Module::~auto_ptr()+0x1f)[0x82af817]
llvm-ld(llvm::Linker::LinkInArchive(llvm::sys::Path const&,
bool&)+0x618)[0x82de55a]
llvm-ld(llvm::Linker::LinkInLibrary(std::basic_string<char,
std::char_traits, std::allocator > const&, bool&)+0x239)[0x82d09b3]
llvm-ld(llvm::Linker::LinkInItems(std::vector<std::pair<std::basic_string<char,
std::char_traits, std::allocator >, bool>,
std::allocator<std::pair<std::basic_string<char, std::char_traits,
std::allocator >, bool> > > const&,
std::vector<std::pair<std::basic_string<char, std::char_traits,
std::allocator >, bool>, std::allocator<std::pair<std::basic_string<char,
std::char_traits, std::allocator >, bool> > >&)+0x87)[0x82d0c51]
llvm-ld(main+0x5e2)[0x82ac518]
/lib/tls/libc.so.6(__libc_start_main+0xd3)[0x670de3]
llvm-ld(__gxx_personality_v0+0x149)[0x82a4041]
Aborted

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 17, 2007

assigned to @lattner

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 17, 2007

This is confirmed. I can replicate the behavior.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 17, 2007

The debugger is not being friendly on this one. There is a use of a linked
function remaining that causes the assertion. It is supposed to print out
details about that, but doesn't. Furthermore, I can't get the debugger to break
in there so it is really hard to figure out where the dangling use is coming from.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 18, 2007

This is also a problem on the release 2.0 branch so its been around for at least
a week.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 18, 2007

This build is OK: "2007-05-04 7:00".

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 18, 2007

Thanks Zhiru, that helps. Perhaps I can find it by comparing changes since then.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 18, 2007

I've tracked it down to being just a problem with archives. The only difference
since May 4th is that it was changed to work with BitCode. As I suspected, I
think there's some interaction between ModuleProvider and BitCode that is
causing the Module to be created incorrectly.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 18, 2007

@lattner
Copy link
Collaborator

lattner commented May 18, 2007

This is a serious regression from 2.0.

Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070514/049805.html

Testcase here: test/Linker/link-archive.ll

Many thanks to Reid for helping put the pieces together and create the testcase.

-Chris

@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
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:bitcode regression
Projects
None yet
Development

No branches or pull requests

2 participants