[Kazan]

StrattComm your roommate is talking out his arse

he found a 'solution' that solves the symptom, not the problem

floating points in comparisions don't cause any problems either

this is a memory overwrite somewhere

[StratComm]

He didn't find the "solution" and the symptom is of the problem of not accounting for the sometimes odd ways that computers deal with floating point variables.  In general a proximity comparison is preferable for floating points (within set range of # rather than logical equals) as it allows for small miscalculations and inconsistancies to be overlooked.  He actually pointed me to a discussion on TopCoder that discussed just such a crash, and that was the basis for my post what, two weeks ago.  And I didn't say he looked at the code and dug up a the solution either, he just pointed out something (originally discussed on TopCoder I believe) that has appeared before, can cause a program to crash, only shows up in rare instances, and is a genuine pain to trace and debug.  As for him "talking out his arse," he is one of the best C++ coders you'll ever meet so it wouldn't hurt to at least take it under advisement.  It's not the only possibility for the crash or even a likely one, but it is possible.

[ynaig]

From reading the posts about the crash I think it might be worth taking in consideration the produced code by the compiler cause when I was working on a big project, I was experiencing strange crashes that was never caught in the debug version, and after testing and going thru the assembler code produced by the compiler for the release code, i found a small bug, a mismatched stack frame register that wasn't supposed to be there. The problem caused by that was that there were too many functions/classes in one file that might have caused the compiler to misproduce one byte of code, and it was gone by just dividing the big source file in smaller files.

Just telling my story in hunting a devious bug.

Ynaig

[Goober5000]

Hm.  Ynaig, would you like to take a look at the code?  Say the word, and we'll give you an avatar and private forum access.

[phreak]

you seem to enjoy pain.  you'll fit right in

[ynaig]

Originally posted by Goober5000
Hm.  Ynaig, would you like to take a look at the code?  Say the word, and we'll give you an avatar and private forum access.

Well I did a cvs for fs2_open and i saw that the file named hudtarget.cpp is way over 170KB and I know from my experience that big source files always compromises the compilers' ability to produce good code. Please take in consideration to break it in smaller files, as I can't successfully compile the entire fs2_open with VS.NET 2003. I keep getting lots of errors like "code\graphics\2d.h(561) : error C2383: 'screen::gf_set_palette' : default-arguments are not allowed on this symbol". At one moment it barfed with compiler internal error, meaning that the compiler ran out of memory or resources when trying to compile a file. I have 512MB so it's enough for compilation, but again I speak from experience that such big source file spells trouble for compiler.

Best regards,
Ynaig

[Goober5000]

You downloaded the source; you're in.

[Sandwich]

Yes, he is.

[ynaig]

I tried to compile the source code with VS.NET 2003 but to no avail, I keep getting lots of errors as i stated above. I guess the project is for VC6 which i don't have it anymore. Sorry. If i could have time to edit all the source files to compile under VS.NET 2003 i could help, but my time is limited.

Ynaig

[Kakis]

I'm missing the file "amvideo.h" which prevents me from compiling. Where can I get it?