Hi,
I found a couple cases in libelf that look like they need some extra locking. I assumed that the client has control over the lifetime of Elf structures, which is to say that I didn't try to fix the race between releasing memory allocated for struct Elf in one thread, and trying to lock the same Elf in other thread.
The changes are on pmachata.threads branch.
PM
I found a couple cases in libelf that look like they need some extra locking. I assumed that the client has control over the lifetime of Elf structures, which is to say that I didn't try to fix the race between releasing memory allocated for struct Elf in one thread, and trying to lock the same Elf in other thread.
Right. If elf_end was called on the last ref, then any other simultaneous call on the same Elf handle is invalid.
The changes are on pmachata.threads branch.
I forked your branch after the libelf-only changes, added in the one later libelf commit and a nit tweak of my own, and put that on the new temporary branch "com.redhat.elfutils.roland.pending.libelf-threads". I then propagated that to com.redhat.elfutils.pmachata.threads so your later merging should be happy.
If it looks OK to Uli, .roland.pending.libelf-threads can be merged to the trunk now. I'd like to separate that from reviewing the libdw work.
Thanks, Roland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've propagated the changes, fixed a bug, and then pushed the changes.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
elfutils-devel@lists.fedorahosted.org