Custom Query (245 matches)

This happens with the current trunk (064x) under the following conditions:

1. A process using LIBC063.DLL is up and running so that the __LIBC_SPMHEADER structure is already created in the shared memory.

2. A process using LIBC064x.DLL is getting started which results in the above error message.

Debugging LIBC064x.DLL shows that the message appears because the DosOpenEventSem?() here​ returns ERROR_INVALID_HANDLE on a handle which looks OK here (0x800103C or like that).

Note that spmInit() in LIBC063.DLL doesn't do DosOpenEventSem?() (which is not fully clear since this call is kind of required to make use of the semaphore from another process) and therefore if the second process is LIBC063.DLL-based, it starts fine.

If the process connects its stdin/out/err handles to pipes using DosDupHandle?() and then starts a child with spawn*() (perhaps, fork too?), isatty() called in the child one will return 1 for stdin/out/err while they are actually pipes, not character devices any longer.

In fact, calling isatty() in the parent process after DosDupHandle?() will continue to return 1 too.

My guess is that once LIBC has cached imported file handle information, it is never refreshed. I see these options:

1. Don't cache information for imported file handles but instead always fetch it from the system. The question is the performance impact.

2. Provide a custom libc extension (available to end user programs) that resets the cache of imported file handles. This extension is to be called by the end user program when it manipulates file handles bypassing LIBC (as in case of DosDupHandle?()) as well as by spawn*() and fork().

3. A combination of 1 and 2. I.e. reset the cache for the particular handle in public calls like isatty() but still use the cached information internally (i.e. through libc_FH, etc.). This should not have a big performance impact and still free the programmer from caring about this cache at all (which is a good thing).

It is known that some OS/2 system DLLs and some third party DLLs unexpectedly reset the FPU control word to a value that causes FPU exceptions to be thrown by the CPU. This may happen to any application, no matter what compiler and runtime it uses. Even if the application doesn't load the "viral" DLL directly, it may be injected into the process by the system (i.e. via PM DLL hooks).

However, according to ​IEEE 754, the default action for FPU exceptions (e.g. divide by zero) in the compatible C runtime is to return a special value (e.g. Inf, infinity).

This often leads to a situation when the program does something like float f = 1.0 / .0; and expects to get an appropriate result (Inf in this case) but instead it gets a SIGFPE and unexpectedly terminates (crashes). There are dozens of user bug reports like that and they continue to come from time to time.

Some applications work around this issue by manually calling _control87() at appropriate times to restore the default IEEE FPU CW value that masks off all exceptions. However, this doesn't always work. First, there may be many places that can indirectly cause an exception and it's very hard to track them all to insert a _control87() call. Second, even if it's done, it's still theoretically possible that the viral DLL kicks in between. The only ultimate solution for the application is to install a system exception handler for each of its threads, intercept all FPU exceptions, reset the control word and retry.

In fact, virtually any application needs this fix, for any of its threads (including threads created by third party library functions). Doing this over and over in each application is a pain. Functionally this definitely belongs to the C runtime. Normal programs (including third party libraries) are expected to start new threads using beginthread(). And this is what most applications do.

So the FPU exception handler must be installed by LIBC both for main() and for all threads started with beginthread().

PS. GCC on Mac shows the correct behavior, no SIGFPE when I do things like float f = 1.0 / .0;. This is just to show that this is the expected behavior of the modern compiler.