0

I am working in a project where I must interface between managed code and unmanaged code. I am currently having a strange issue with math.h.

Some functions will floating numbers will returns 0 (ex: 2.1219957934356005e-314) and randomly...

By example:

int error = 0;
int success = 0;
for (int i = 0; i < 1000; ++i)
{
    double test = std::sqrt(9.01);
    if (test < 2 || test > 4)
    {
        ++error;
    }
    else
    {
        ++success;
    }
}

Usually I will obtain error = 1000 with breakpoints, I'll retry it some times and get again 1000 errors and some times I will get 1000 success...

I see nothing wrong into the dissassembly and into the registers (except the bad result).

For context: this code is compiled into a dll for 64 bits and is used by C#. This app is indeed multithreaded.

Any idea?

Cory Kramer
  • 114,268
  • 16
  • 167
  • 218
Nic007
  • 634
  • 5
  • 13
  • The code you provided should produce no such errors. If you have threaded code you'll have to show the relevant parts of that. It is hard to say what could cause an error like that without seeing the code. – Cory Kramer Feb 17 '15 at 22:33
  • Are you locking threads while test is being changed?/initialized – huseyin tugrul buyukisik Feb 17 '15 at 22:34
  • I have a lot of threads, this one has been tested on two different threads with the same result (I don't have any relevant code to show). I don't think I would need locks because for this test all variables are local and no memory is shared. Unless math.h use some static and global variables? – Nic007 Feb 17 '15 at 22:37
  • 1
    It depends on your toolchain, but math.h is generally thread-safe. – Lightness Races in Orbit Feb 17 '15 at 22:57
  • Good luck with this, OP, but there's no reproduction here and I don't see how we can debug it for you remotely. #vtc – Lightness Races in Orbit Feb 17 '15 at 22:57
  • I have a feeling that threading is a red herring here. Dunno why. Check the generated assembly. /fastfp and other optimization/conformance flags. There's bound to be a register context difference. And yes, that would seem to be a library/compiler bug. – sehe Feb 17 '15 at 23:05

1 Answers1

1

I think I solved a part of my problem (I must do more tests).

The main problem was caused by the fact that my project changed to clr (managed code) for everything. With more research I found that I can compile specific files of my project with the property clr set to no. Now all my old native source code is compiled as native. But it still doesn't explain why functions like sqrt(), ceil(), etc. does not work everytime in managed context.

Now I must resolve bugs with OpenGL, but that's another story :D (This project is an abomination!)

Nic007
  • 634
  • 5
  • 13