[LLVMbugs] [Bug 22482] New: gold+gold-plugin may unmap file before done

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Feb 5 13:31:22 PST 2015


            Bug ID: 22482
           Summary: gold+gold-plugin may unmap file before done
           Product: tools
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: gold-plugin
          Assignee: unassignedbugs at nondot.org
          Reporter: jvoung at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I've run into a situation where a 32-bit linux LLVM + gold-plugin + binutils
will unmap a file view in getModuleForFile(), and then try to access the file
view buffer after that.

Timeline is roughly:


getModuleForFile(...) {

  ld_plugin_input_file File;
  if (get_input_file(F.handle, &File) != LDPS_OK)
  // ... 

  const void *View;
  if (get_view(F.handle, &View) != LDPS_OK)
  // ...

  // ... View is fine. It points to the mmap'ed version of the file contents.

  // Set up Buffer/BufferRef based on the View

  if (release_input_file(F.handle) != LDPS_OK)

  // ... View is no longer fine. release_input_file **may** end up unmapping.

  // Attempt to access the buffers more, and crash.
  // ...



I've only been able to reproduce this where binutils and llvm are built as
32-bit executables. Things work fine as 64-bit executables, and the
release_input_file() does not unmap the view.

For 64-bit gold's File_read::clear_views() hits this case:

      else if ((p->second->should_cache()                                       
        || p->second == this->whole_file_view_)                                 
           && keep_files_mapped)                                                
    should_delete = false;                        

and then does not delete the view, while on 32-bit it does.

I'm not sure exactly why yet, but I'm wondering if the gold-plugin's call to
release_input_file() should be later.

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/20150205/dbf614f5/attachment.html>

More information about the llvm-bugs mailing list