lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Alien msvc rtl dll messing with the fpu?


From: Vadim Zeitlin
Subject: Re: [lmi] Alien msvc rtl dll messing with the fpu?
Date: Thu, 12 Jan 2006 16:37:55 +0100

On Tue, 10 Jan 2006 18:30:22 +0000 Greg Chicares <address@hidden> wrote:

GC> I just received a problem report indicating that the floating-point
GC> hardware control word is changed while lmi is running.

 And I guess we don't know when does it happen, right? To be honest I don't
know how could something like this be detected except by sprinking the code
with calls to _control87 and asserting (or logging?) if it changed.

GC> It's strikingly similar to this:
GC> 
GC>   http://community.borland.com/article/0,1410,17627,00.html

 This seems *very* old. I'm far from sure it has any relationship with the
problem at hand.

GC> In those days, calling LoadLibrary("commctrl.dll") on startup, then
GC> reinitializing the fpu, was a fairly effective safeguard. Later, I
GC> guess that became "comctl32.dll", but now I don't find either on my
GC> msw system.

 The "normal" comctl32.dll should still exist in your windows system32
directory. But it is not used with themes which are only implemented by
comctl32.dll version 6 which is "hidden" in
WinSxS\x86_Microsoft.Windows.Common-Controls* subdirectory.

GC> I suspect that this stems from some process that lmi spawns for
GC> printing--adobe 'acrobat', perhaps, or apache 'fop', which is java
GC> and loads a jvm.

 I'm sorry, do you really mean that another process can change the FP
control word for lmi?? I admit that I didn't test it but I hope Windows
keeps separate FP control word for each process.

GC> I think it's still possible, though, for a completely separate
GC> process to cause this problem, probably by loading a copy of some
GC> redistributable msvc rtl dll. Do applications typically dump copies
GC> of such dlls into the system directory as they used to?

 Hopefully not.

GC> I guess I could enumerate all the 'msvcrt*.dll' files there and load
GC> them all

 The best would be to put a breakpoint on LoadLibraryW API call and check
the control word before and after it. Using something like Microsoft
detours library, it could even be done non interactivaly.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]