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

ValueSymTab::insert can loop infinitely #1568

Closed
llvmbot opened this issue Feb 11, 2007 · 4 comments
Closed

ValueSymTab::insert can loop infinitely #1568

llvmbot opened this issue Feb 11, 2007 · 4 comments
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:core

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 11, 2007

Bugzilla Link 1196
Resolution FIXED
Resolved on Nov 07, 2018 00:17
Version trunk
OS All
Reporter LLVM Bugzilla Contributor

Extended Description

When llvm-upgrade calls Value::setName from setValueName it ends up attempting
to insert a value in the symbol table. This can recurse infinitely in this loop:

// Otherwise, there is a naming conflict. Rename this value.
std::string UniqueName = V->getName();
unsigned BaseSize = UniqueName.size();
do {
// Trim any suffix off.
UniqueName.resize(BaseSize);
UniqueName += utostr(++LastUnique);
// Try insert the vmap entry with this suffix.
} while (!vmap.insert(make_pair(UniqueName, V)).second);

Last night's nightly test was halted by this. It looped 22,821,681,606 times
before I broke into it with the debugger. Its unclear why the map is refusing to
insert the new name.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 11, 2007

This affects llvm-as and all deja-gnu tests as well, its not specific to
llvm-upgrade.

@lattner
Copy link
Collaborator

lattner commented Feb 11, 2007

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 11, 2007

Yup, that fixed it.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 12, 2007

64bit failure
just for completeness, this patch also seems to solve a bug involving running
the attached file though llvm-as on alpha. Things in the symbol table would
get trashed (Value* becoming garbage) and lost, and lookups of stuff that
should be in there resulted in triggering the conflict-so-rename code in
insert. This didn't affect x86.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
…e84cbba071b1ff4f6341

[lldb] Add copy ctor/assignment operator to SBCommandInterpreterRunOp…
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:core
Projects
None yet
Development

No branches or pull requests

2 participants