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: [email protected]
Reporter: [email protected]
CC: [email protected]
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.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
