Stack overflow in cos()

I am having troubles with the cos() function.

I have two threads which are calling a member function using cos(). This class is synchronized properly so that the two threads cannot be executing this code ate the same time. Anyway, cos is reentrant.
The fact is that one of these thread(always the same) generates a stack overflow in cos() when cos() is in a member function.
If the cos() call is directly in the thread's main loop, there is no problem.

It is not the first time I do this kind of operation but now it fails. What could be the source of all this?

Any idea about it will be welcome.

1) Is it possible to attach a simple test program that you know will cause the stack overflow?
2) What OS are you using (Unix, Windows ...)?
3) What sort of threads are you using (pthreads, SunOS threads, Windows threads, Windows fibers)

I am using WinCE. Of course, I use Windows threads.
It would be hard to include a sample which cause the trouble as it is in the middle of big project. Also, it is the first time I am having a problem of this kind but not the first time I code such a thing.
In fact, this code was working good since recently and I have not modified anything(or should I say: something was modified and I don't know what it is).

I hope it is enough to enlighten you.

Thanks.

Fred

Fred,

Hmmm, this sounds tough.

You say the call of cos() generates a stack overflow when the call of cos() is in a member function, as opposed to in the main thread loop. Is the member function a member of an MFC class (Microsoft Foundation Classes), or is the class standalone?

I have actually encountered several problems, sometimes stack problems but more often heap problems when Windows threads are mixed with MFC class objects and each one of these entities calls static functions such as cos().

Please also check to be sure that your program is compiled and linked with a multithreaded version of the standard C runtime library. Check the project settings dialog, C/C++ tab, "Use Runtime Library" = Multithreaded (not Single Threaded).

Sometimes there are bugs in projects. If you expect that the threads are synchronized, but some bug crept in and they are not, then one of the threads could be doing rapid, back-to-back calls of cos(). This will definiely lead to big memory troubles.

You need to isolate your problem.

Write a helper Debug routine such as double my_cos(double), a global public function which does the call to cos(). Call this function instead of cos() and use a good debugger and possibly write debug code in order to isolate the memory addresses and calling frequencies associated with this problem. I will write in plain C.

double my_cos(double x)
{
// The use of the volatile intermediate variable
// forces the result to be placed into a variable
// which has a physical address (i.e. not a CPU register).
// This will give you insight into the memory region
// accessed by your program.
volatile double result;

// Examine this address (the value of p_result)
volatile double* p_result;

result = cos(x);
p_result = (volatile double*) &result;

return result;
}

Play around with this helper subroutine.
Look at the value of p_result using a good debugger. Change the storage class of "result" from "volatile" to "static" and re-investigate. Count up, for example, the frequency of calls to my_cos and make sure that the results meet your expectations.

You will find a solution using a helper function and debug code.

If you can't find any problems with your usage of cos() and your program runs only with the use of my_cos(), then there truly could be some issue with the compiler/linker. This would be a bug in the memory management.

Good luck.
Chris.

:)