[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
http://llvm.org/bugs/show_bug.cgi?id=22482
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