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

[Greg Chicares]

On 2006-1-12 15:37 UTC, Vadim Zeitlin wrote:
> 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?

It seems to be associated with printing, which
 - spawns apache 'fop', which loads a jvm; and
 - spawns the adobe 'acrobat' pdf viewer; and
 - prints output, interacting with system printer drivers.

> 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.

I rebuilt the test program given there, using contemporary tools from my
collection of antique borland compilers. It no longer fails: the workaround
it uses is no longer necessary. Just for the record, that message lacks
header names, probably because anything in angle brackets looks vaguely like
an html tag; these headers suffice, in case anyone else wants to build it
someday:

  #include <windows.h>
  #include <windowsx.h>
  #include <fstream>
  #include <iostream>
  #include <commdlg.h>
  #include <stdio.h>
  #include <float.h>

> 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??

That's what we seem to be observing. On exit, a messagebox says:
  The floating-point control word is unexpectedly '27f'.
when the problem occurs. That's the value ms advocates. I'm sure I never
set it that way. I take care to initialize it to 0x037f, the hardware
default that intel recommends.

> I admit that I didn't test it but I hope Windows
> keeps separate FP control word for each process.

Years ago, it didn't. Here are some links that I categorize only by OS
version:

http://www.speakfreely.org/development_log.html
  msw 95

http://groups.google.com/group/microsoft.public.ddk.win9x.printer.drivers/browse_thread/thread/6fd883ab0e2d6c09/c358ec7a10245f9f
  msw 9x

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4644270
  msw nt 4.0; java2sdk-1.4.2

http://groups.google.com/group/microsoft.public.win32.programmer.directx.graphics.shaders/browse_thread/thread/3553c20f1544c69e/a27a68c730c940f2
  msw versions through xp

http://groups.google.com/group/comp.std.c/browse_thread/thread/9e2fcb7c936f0016/1c085bbb74034778
  64-bit msw

Those links span many years, but some aren't very old at all. None of them
really explains what we're seeing, though.

And I can't induce the problem described in that old borland link with the
test below. I ran this program in two different shell sessions:
  start first instance,    e.g. ./fpu_cw foo 0x037f
    start second instance, e.g. ./fpu_cw foo 0x040f
    end second instance
  end first instance
and wasn't able to get one to interfere with the other.

// file fpu_cw.cpp
// $/MinGW-20050120/bin/g++ -I /lmi/src/lmi fpu_cw.cpp -o fpu_cw

#include "fenv_lmi_x86.hpp" // from lmi

#include <iomanip>
#include <iostream>
#include <ostream>
#include <sstream>
#include <string>

int main(int argc, char* argv[])
{
    if(3 != argc)
        {
        std::cerr
            << "Usage: fpu_cw name cw, where\n"
            << "  name is a name to identify the process\n"
            << "  cw is an intel control word such as 0x037f\n"
            << std::flush
            ;
        return 1;
        }
    std::string s;
    std::istringstream iss1(argv[1]);
    iss1 >> s;

    unsigned short int cw;
    std::istringstream iss2(argv[2]);
    iss2 >> std::hex >> cw;

    x87_control_word(cw);
    std::cout << "Press Enter to continue." << std::endl;
    std::cin.get();
    std::cout << s << ": " << std::hex << x87_control_word() << std::endl;
}

And here's another test that spawns the above program (to be precise, it
invokes CreateProcess()):

// file fpu_cw_caller.cpp
// $/MinGW-20050120/bin/g++ -I /lmi/src/lmi fpu_cw_caller.cpp 
/lmi/src/lmi/system_command.cpp -o fpu_cw_caller

#include "fenv_lmi_x86.hpp"
#include "system_command.hpp"

#include <iomanip>
#include <iostream>
#include <ostream>

int main()
{
    x87_control_word(default_x87_control_word());
    std::cout << "parent: " << std::hex << x87_control_word() << std::endl;
    system_command("fpu_cw foo 0x027f");
    std::cout << "parent: " << std::hex << x87_control_word() << std::endl;
    system_command("fpu_cw bar 0x0040");
    std::cout << "parent: " << std::hex << x87_control_word() << std::endl;
}

Output:

  $./fpu_cw_caller.exe
  parent: 37f
  Press Enter to continue.

  foo: 27f
  parent: 37f
  Press Enter to continue.

  bar: 40
  parent: 37f

which shows that spawned processes don't affect the parent,
at least not with the msw version I'm running.