[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