Re: Use GetErrorMode if it is available (on Windows Vista and above).

[Peter Rosin]

Den 2010-01-12 21:19 skrev Ralf Wildenhues:
> Hi Peter,
>
> * Peter Rosin wrote on Tue, Jan 12, 2010 at 11:00:17AM CET:
> > Without the patch, a separate thread of the process could be relying on
> > the error mode to have some specific flag. Then, during a small window
> > the loadlibrary loader clears some vital error mode flag since it has
> > to set a temporary error mode (which might be insufficient for that other
> > thread) to retrieve the existing error mode. There is a possibility that
> > things go downhill due to that race. With the patch (and GetErrorMode
> > support) the loader can fail critical errors (i.e. no irritating popup
> > dialog) without clobbering other error mode flags in the process.
>
> I'm still not sure I understand.  FWIW, in Libtool 2.x, we decided that
> internal locking in libltdl was not feasible/possible correctly, and we
> now require that users of libltdl do not call its functions
> simultaneously from different threads.  In practice, that also means
> that different threads may not call the underlying loader functions (be
> that dlopen or LoadLibrary) at the same time, but I'm not sure whether
> we communicate that in the manual.
>
> Does the above descriptions only hold for LoadLibrary-related functions
> (in which case that seems to be a user error in the code using libltdl)
> or for any kind of library functions that set an error mode?  Is "error
> mode" on w32 something akin to errno?

The problem is that before this fix (and when GetErrorMode isn't provided)
we introduced a small window where a process depending on the error mode
didn't behave as expected.

The error mode basically controls which errors should generate a popup
and which errors should just be indicated with a returned error code.
(The SetErrorMode docs is easy accessible, it's the first hit on google)

One error mode flag is SEM_NOGPFAULTERRORBOX, which makes it apparant
that it's not really feasible to do as you suggest as that would
require client code (in different threads) to not generate any general
protection faults when calling ltdl, effectively making ltdl only
safe to use in single-threaded apps (at least when using the loadlibrary
loader).

Reading the docs for SEM_NOGPFAULTERRORBOX indicates that it should only
be used by "debugging applications" that handles GPFs themselves, but
I believe it to be fairly common to set the flag to disable the crash
dialog by other apps as well.

> > That said, a potential race is still there since the error mode is
> > process global and we are trying to save the current error mode and
> > restore it afterwards, some other thread might do the same and we'd get
> > into an inconsistent state if unlucky. There's no way to deal with that
> > though, short of adding some locking mechanism and requiring client code
> > to follow our lead.
>
> That sounds like we may simply need to document that the client code
> needs to employ locking so that libltdl functions are not called
> simultaneously as function set X, X being?

See above, that would require all other threads to be stopped during the
ltdl interaction, which is a wee bit heavy handed...

With this fix, we can say that client code should not /set/ the error
mode during calls to ltdl, which is much less limiting (at least on up
to date OSes, i.e. those w/ GetErrorMode).

But the impact of all this is not really that big, let's drop the patch
if you think it's too pedantic. I just wanted to do the best possible
thing, and the patch isn't exactly intrusive...

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?