Re: [patch] Re: dlopen() and dlclose() are not MT-safe?
- From: Kazuaki Oda <kaakun@xxxxxxxxxxxxx>
- Date: Thu, 23 Mar 2006 22:19:28 +0900
Kostik Belousov wrote:
The reasoning behind releasing the lock is to allow calls to dl*()
functions from constructors/destructors. This is common practice
and shall be supported. Yes, leaving the lock taken will lead to
deadlock.
Please, try the following patch and report results. I can run (modified *)
version of your test for some time without crash with both libpthread
and libthr.
[* You need to allow for errors in dlopen and just continue the loop.]
Patch protects access to the list of unloading objects by bind lock,
and marks the objects that are running finalizers to prevent
simultaneous loading of them.
Also, it comments out code that is completely incomprehensible by my sloppy
brain. Namely, the thread_mask_set stuff seems to allow for the thread
to run as-is if another thread taken the lock. As result, lock is
effectively ignored. I cannot understand purpose of this fragments.
Hope, kan@ describe the reasons.
Thanks. I tried your patch, and the test program did not crash any more. But I needed to modify it as you say. IMHO there are probably programs in the world that don't retry in case of errors in dlopen(), so they still have problems in such case..
--
Kazuaki Oda
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- References:
- dlopen() and dlclose() are not MT-safe?
- From: Kazuaki Oda
- Re: dlopen() and dlclose() are not MT-safe?
- From: Kostik Belousov
- Re: dlopen() and dlclose() are not MT-safe?
- From: Kostik Belousov
- Re: dlopen() and dlclose() are not MT-safe?
- From: Kazuaki Oda
- [patch] Re: dlopen() and dlclose() are not MT-safe?
- From: Kostik Belousov
- dlopen() and dlclose() are not MT-safe?
- Prev by Date: Re: [patch] Re: dlopen() and dlclose() are not MT-safe?
- Next by Date: Re: Installation from USB pen
- Previous by thread: Re: [patch] Re: dlopen() and dlclose() are not MT-safe?
- Next by thread: Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
- Index(es):
Relevant Pages
- Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler
... existed of a set of patches suitable ... plus an additional patch for
Preempt-RT only. ... the splitup of the interrupt handler was also needed for ...
* uart_start, which takes the lock. ... (Linux-Kernel) - Re: [PATCH 0/5] ppc RT: Realtime preempt support for PPC
... checks the value of lock is assembly and treats lock as signed. ... Thus it
is also OK that you left this chunk out of your patch. ... Patch #4 went in via
the PPC tree. ... (Linux-Kernel) - Re: Giantless VFS.
... On Sat, 2004-11-20 at 00:24 -0500, Jeff Roberson wrote: ... > I have a patch
that I would like people to test and review. ... > This patch removes Giant from the
read, write, and fstatsyscalls, ... > number of lock operations for the common cases
which resulted in a couple ... (freebsd-current) - Re: [patch 6/8] 2.6.22-rc3 perfmon2 : IBS implementation for AMD64
... pls. see 2nd patch version. ... 'count' may only be incremented if the PMD
is used. ... It seems this function is only called if the lock is set, ... Operating
System Research Center ... (Linux-Kernel) - final SCSI updates (hopefully) for 2.6.0
... The patch is here ... o scsi device ref count ChangeSet@1.1482 ...
* the list, and freeing @sdev. ... # the lock again to traverse the list. ...
(Linux-Kernel)