[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fixing libpthread noload, another approach
Martin Husemann <martin%duskware.de@localhost> wrote:
> You point out the real bug pretty prominently here, don't you?
> What is it using libgobject for? Can that be split out in a separate binary
> (i.e. to run UI configuration dialogs or whatever, but leave the real PAM
> module untainted)?
Take liblasso, which is something perfectly relevant to be used by a PAM
module. It depends on libgobject, mostly for g_hash, g_list and g_slist,
which seems quite reasonable.
The problem is thatlibgobject also embed thread-related stuff, but are
you going to tell GNOME people what features they should fold in their
libaries because of
> Your suggestion, overall, returns the state to something similar than we
> had before - random runtime failures.
Not quite. Current situation is silent failure of dlopen (unless logs
are correctly configured) for:
- legitimate use, as in the liblasso example
- buggy sitation where pthread_create would be attempted later.
My patch turns it into:
- legitimate use works as it did before
- buggy situation (pthread_create call) aborts reliabily at runtime.
And as proposed in another message, if we are going to abort the
program, we could openlog/syslog before to make sure the errors makes it
to the log, that will not harm the program.
Main Index |
Thread Index |