[LLVMbugs] [Bug 13522] New: Subtle precondition in StructType::setName
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Aug 3 08:40:35 PDT 2012
http://llvm.org/bugs/show_bug.cgi?id=13522
Bug #: 13522
Summary: Subtle precondition in StructType::setName
Product: new-bugs
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: hammacher at cs.uni-saarland.de
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
I just stumbled across an error that valgrind reported ("read after free"), and
I tracked the cause back to the StructType::setName method. The problem only
occurs when you pass a StringRef, which *uses* the old name.
For example, if you want to remove everything following the first dot, and you
write
Ty->setName(Ty->getName().split('.').first)
What happens then is that inside the setName method, first the old name is
removed from the NamedStructTypes mapping, but this operation frees the
StringMapEntry which is also referenced from the StringRef for the new name.
Later, when this new name should be added to that mapping, valgrind detects the
usage of freed memory.
What can we do about this?
1) forbid passing a StringRef which uses the original name. This is effectively
the status quo, but it should be asserted explicitely in the setName method,
since IMHO this kind of error is hard to spot. Checking is the data pointer of
the new name is inside the current name is cheap.
2) allow this, by detecting the situation and copying the new name to a
SmallString on the stack.
What do you think?
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list