[llvm-bugs] [Bug 30584] New: "Offset out of bounds!" assertion in SectionEntry::getLoadAddressWithOffset in RuntimeDyldImpl.h

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=30584

            Bug ID: 30584
           Summary: "Offset out of bounds!" assertion in
                    SectionEntry::getLoadAddressWithOffset in
                    RuntimeDyldImpl.h
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: j4_james at hotmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

This occurs when using the lli interpreter on Windows to execute code
containing a global array reference with a negative offset. Here's a short C
example that will trigger the problem.

  static int data[1] = {1234};
  int readData(int n) { return data[n-1]; }

  int main() {
    return readData(1);
  }

I believe this is a regression caused by the changes in revisions 253918 and
253919 where this expression:

  Sections[RE.Sections.SectionA].LoadAddress + RE.Addend

was changed to this:

  Sections[RE.Sections.SectionA].getLoadAddressWithOffset(RE.Addend)

This included the addition of boundary checking in the getLoadAddressWithOffset
method to make sure the given offset was contained within the section. The
problem is that the Addend argument is signed, while the parameter expected by
the getLoadAddressWithOffset method is unsigned. A negative offset is thus
converted to a large unsigned value that will inevitably be out of range.

Actually even an unsigned value could potentially trigger the bug if large
enough, because the Addend offset is not guaranteed to fall inside the
section's boundaries.

Anyway, the simple solution would be to bypass the range check by changing that
expression to something like this:

  Sections[RE.Sections.SectionA].getLoadAddress() + RE.Addend

I should be clear that this is just a partial fix though. It works, but only
because there are a couple of other bugs that have conveniently aligned
themselves to produce the correct result. :) Those issues can probably be
addressed separately though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161001/25817e69/attachment.html>