Stack overflow with sqrtf

Hi,

No doubt I am doing something stupid, but I cant get to the bottom of this error, so any help would be massively appreciated! I came across it using dx9.0c, calling the D3DXVec3Length function. Using this function with a certain D3DXVECTOR3 caused:

Unhandled exception at 0x102c6502 (msvcr80d.dll) in blah.exe: 0xC00000FD: Stack overflow.

With the code breaking at:

Code:

---

D3DXINLINE FLOAT D3DXVec3Length
    ( CONST D3DXVECTOR3 *pV )
{
#ifdef D3DX_DEBUG
    if(!pV)
        return 0.0f;
#endif

#ifdef __cplusplus
    return sqrtf(pV->x * pV->x + pV->y * pV->y + pV->z * pV->z);  // BREAKING HERE!
#else
    return (FLOAT) sqrt(pV->x * pV->x + pV->y * pV->y + pV->z * pV->z);
#endif
}

---

So I thought instead I will write my own vector length function, using the same idea. Sure enough it had the same problem. By using breakpoints I stopped it before its stack overflow and found that the vector was:

pV->x = 0.11898671
pV->y = 0.077150002
pV->z = 0.0

Meaning that the sqrt function's input is 0.020109955. I next tried just writing the code:

Code:

---

        sqrtf(0.020109955f);

---

...which caused the same over flow. Changing the number to something else however appears to work.

So what glaringly obivous thing have I missed? Is there just something I do not know about the square root function? I am using VC++ 2005. Cheers for any input on this,

Skusey

I don't think the problem is with the sqrtf itself. I think that the number you're passing it is so low that the result is 0, which causes problems elsewhere. Did you try something like this?

Code:

---

#include <iostream>
#include <cmath>

int main() {
    std::cout << std::sqrtf(0.020109955f) << std::endl;

    return 0;
}

---

Does it crash? Does it print 0?

The only other thing I can think of comes from here: http://www.cprogramming.com/fod/sqrt.html

Quote:

---

Explanation: Returns the square root of Value. Probably not a good idea to try a negative number for Value...

---

but you already established the value, and it isn't negative . . .

BTW, C has sqrtf(), too; why do you have a #ifdef __cplusplus there?

Quote:

---

Originally Posted by dwks

I don't think the problem is with the sqrtf itself. I think that the number you're passing it is so low that the result is 0, which causes problems elsewhere.

---

The square root of a number between 0 and 1 is greater than that number, so I consider this not very likely.

Hmm, you're right. I must have been thinking of something else. :) Well, that makes it even less likely that the sqrtf() is the problem, unless the resulting number is too large.

Yes, I tried that code, and I get the overflow again. In any context I have tried the overflow occurs :(. As for the #ifdef __cplusplus code, that is from one of the DirectX header file, not my own code. Its definately not being passed negatives either, making sure of that in the code.

I just cant work out why on earth it keeps doing it, very frustrating.

Hmm, what happens with a value slightly above or below the critical number?

That seems very weird. I don't know what could be causing it.

Do you have another compiler you could test that code on?

The minimal test compiles and runs fine with VC++2003.

GCC 3.4.4, as supplied with Code::Blocks 1.0 RC2, apparently does not define sqrtf inside namespace std, at least not in the GNU stdc++. Someone with more knowledge of both the C and C++ standards than I could perhaps say whether this is allowed or a compliance problem. It should be noted that the library does handle floats as floats in std::sqrt.
Replacing it by std::sqrt makes the program compile and run fine.

Is he technically giving a double where it's expecting a float? But casting a larger value to a float will just cause it to 'round' to a float... right? So I guess I'm wrong, maybe?

Sorry, just thinking outloud...

Ah, sorry I'v been a fool! The stack overflow should have been the clue, all these problems are going on within a potentially recursive function, which clearly is calling itself one too many times, it just appears the sqrtf function is the tipping point each time. As for the changing the number and it working, I had poorly tested that only once, and it had worked, but not under proper test conditions.

Anyway, to make it clear, it's just me screwing up, thanks for everyones help though.

Skusey