<html>
    <head>
      <base href="http://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - gold+gold-plugin may unmap file before done"
   href="http://llvm.org/bugs/show_bug.cgi?id=22482">22482</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>gold+gold-plugin may unmap file before done
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>tools
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>gold-plugin
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>jvoung@google.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvmbugs@cs.uiuc.edu
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>