LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 1196 - ValueSymTab::insert can loop infinitely
Summary: ValueSymTab::insert can loop infinitely
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Core LLVM classes (show other bugs)
Version: trunk
Hardware: All All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords: compile-fail
Depends on:
Blocks:
 
Reported: 2007-02-11 12:23 PST by Reid Spencer
Modified: 2018-11-07 00:17 PST (History)
1 user (show)

See Also:
Fixed By Commit(s):


Attachments
64bit failure (1.04 KB, text/plain)
2007-02-12 11:50 PST, Andrew Lenharth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Reid Spencer 2007-02-11 12:23:25 PST
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.
Comment 1 Reid Spencer 2007-02-11 12:41:38 PST
This affects llvm-as and all deja-gnu tests as well, its not specific to
llvm-upgrade.
Comment 2 Chris Lattner 2007-02-11 13:36:29 PST
Doh.  Uninitialized variable:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044347.html
Comment 3 Reid Spencer 2007-02-11 13:50:12 PST
Yup, that fixed it.
Comment 4 Andrew Lenharth 2007-02-12 11:50:56 PST
Created attachment 654 [details]
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.