crazy problem, need another perspective

[ADoozer]

background: over the last 4 years i have been writing modifications for a popular online game. the modifications are to original source released by the company back in 2002 and until this week i have never encountered this problem.

the zip file containing the code was written to CD in 2004 and has been used multiple times as the foundation of new modifications (all of which have been proven to work through use in servers)

the problem: for some unknown reason, the source for my latest mod has become corrupt. it will compile. but the server chucks an error as soon as people join.

the particular error (according to the debug) is caused in a reset function, where a **(pointer to pointer) becomes trashed. Sometimes this function is called without error (30+ times) without crashing.. but eventually it will be trashed.

now my initial thought was "o damn.. ive made a mess of the code", so i rolled back to the last backup i made and compiled. the same memory problem was present (and this is on a mod that has been in use without problem since april 2005)

as a long shot, i got the CD (with the original unmodified code burnt in 2004) and loaded the workspace... compiled the code and you guessed it.. this memory/pointer error again.

so without explaining all the events of the last 4 days.

the unmodified code on the CD has been attempted to compile on 5 different PCs (in 2 countries.. had a friend helping out in germany) 1 of which was a complete virgin install. the error is identicle on all PCs (debug always goes to the reset function and the "this" pointer in dissassembly is always pointing to trash)

the code, that previously compiled and worked back in april 2005 (the backup) causes the same memory/pointer error as compiling the unmodified code (the backup is obviously unmodified since its last compile), again on multiple machines.

hope you could follow all that.

anyway.. i need a new perspective, ive run out of things to investigate.

if the source on CD was at fault... why have i used it successfully in the past, and also how does the backup develop identical symptoms?

we can rule out intermediate files since a virgin install was used.

we can rule out service packs to visual c++ because the virgin machine didnt have any on it.

why does a source that has been unmodified since april 2005, which the compiled file works perfectly since 2005, now develop the symptoms when compiled.

(NB: i added some debug to the code. the ** addr was originally 0x3399b4c the first few times through the function then randomly went to 0xddddde01 which causes the subsequent error)

if anyone has any ideas on what i can look into now, it will be much appreciated. i realy am stumped for ideas

If somethings hard to do, its not worth doing - Homer Simpson

 

[chipperMDW]

Is the application ever getting any info from an external location? For example, is it ever obtaining any data by "calling home" to some global server that might have a corrupted file? That situation seems likely if it's an online game. In that case, can you try a different server?

It may help to know what game it is.

 

[ADoozer]

hi, thanks for the reply.

the game is aliens vs. predator 2

the file in question is a DLL (object.lto)

to the best of my knowledge the DLL has no interaction with a central server, so i cant see it being a corrupt file in that respect. (plus, if that were the case existing mods would also see the error?!?)

ive had an interesting development since i posted the question.

I managed to contact a fellow modder and he sent me his original copy of the source (again he has used this source for his own particular mods). And lo and behold, identical error.

Im waiting on him getting back to me after he does a compile on his machine to see if his compile also errors.

so.. with that, i am even more confused.

can a project/workspace be time limited?
is it possible some incrimental counter has overflowed?

ill post back when i get the results from my contact.

If somethings hard to do, its not worth doing - Homer Simpson

 

[ADoozer]

well...

i found the problem.

and to be honest im suprised it ever worked (unless something has changed in the STL or the way in which new and delete work).

heres the scenario

get a pointer to a class
[blue]delete[/blue] the existing data (pointed to by the pointer)
do some STL list stuff and a few other things (which i assume is also supposed to update our pointer in some way shape or form)
declare a [blue]new[/blue] class
fill the details
reuse the original pointer (which is now just a series of 0xDD's) and try and call a function.

as ive said... this code is completely unmodified from the files ive been using for 4 years, so ive either been lucky that the [blue]new[/blue] class always is at the original pointer location, or something in the visual c++ environment has changed.

If somethings hard to do, its not worth doing - Homer Simpson

 

[cpjust]

Did you upgrade to a new version of Visual C++?
The STL in 6.0 was kind of, umm... Well, it sucked.

 

[ADoozer]

update:

results from my contact are identical (identical error on original code that has worked for years)

cpjust.. can you offer any more information on "STL in 6.0" sucking.

as ive stated already i used a virgin install (including no updates for visual studio, used the directX sdk that was on the CD with the original code)

looking at the code... im suprised it ever worked... but surely there was something to trigger the consistant problem (america/germany/uk... 2 sources of original code)

its fixed.. but im still looking into it!

If somethings hard to do, its not worth doing - Homer Simpson

 

[cpjust]

The STL in VC++ 6.0 had several bugs in it and reported tons of warnings, even though they were warnings in the STL headers rather than in your code. As a result, you usually had to use #pragma statements to turn off those warnings...