aboutsummaryrefslogtreecommitdiff
path: root/gold/fileread.cc
diff options
context:
space:
mode:
authorNick Gasson <nick.gasson@arm.com>2020-11-02 12:02:05 +0800
committerAlan Modra <amodra@gmail.com>2020-11-03 10:34:51 +1030
commitaf61e84fd2d6eca1273f1d24b8d7b89c5a1441e5 (patch)
tree76c58de8be2981ecd2fdb75fe50f774f61b8639d /gold/fileread.cc
parent0dd05d40de4e935cec7f8a8ab6c07f7382ef1277 (diff)
downloadgdb-af61e84fd2d6eca1273f1d24b8d7b89c5a1441e5.zip
gdb-af61e84fd2d6eca1273f1d24b8d7b89c5a1441e5.tar.gz
gdb-af61e84fd2d6eca1273f1d24b8d7b89c5a1441e5.tar.bz2
gold: ensure file_counts_lock is initialized before using
Since upgrading to binutils 2.35 I've been experiencing random memory corruption related crashes with ld.gold --threads. It's caused by multiple threads concurrently pushing elements onto the shared std::vector in File_read::record_file_read(). This vector is supposed to be protected by file_counts_lock, but that is initialized lazily and might be NULL when File_read::open() is called, in which case Hold_optional_lock silently skips locking it. Fix by calling the initialize() method before attempting to acquire the lock, the same as other places that use file_counts_lock. PR 26827 * fileread.cc (File_read::open): Ensure file_counts_lock is initialized. * testsuite/Makefile.am (check_PROGRAMS): Add a test that passes -Wl,--threads. * testsuite/Makefile.in: Regenerate.
Diffstat (limited to 'gold/fileread.cc')
-rw-r--r--gold/fileread.cc1
1 files changed, 1 insertions, 0 deletions
diff --git a/gold/fileread.cc b/gold/fileread.cc
index f5ca719..0b5228e 100644
--- a/gold/fileread.cc
+++ b/gold/fileread.cc
@@ -212,6 +212,7 @@ File_read::open(const Task* task, const std::string& name)
gold_debug(DEBUG_FILES, "Attempt to open %s succeeded",
this->name_.c_str());
this->token_.add_writer(task);
+ file_counts_initialize_lock.initialize();
Hold_optional_lock hl(file_counts_lock);
record_file_read(this->name_);
}