self compiled version crashes related to save_index

[gfgtdf]

hi i recently tried to compile wesnoth on my own using visual studio 2010 (on windows 7).

After i got rid of some VS 2010 specific bugs, it started well.

but after i have played with the self compiled version a few times, the game always closes itself when loading from a safefile or starting a new campaign.
deleting the file safe_index alway helps, but not for long (then i have to delete it again.)
the issue happens with the 11.2 version aswell as with the 11.5+dev version.

i use the downloadable files from http://wiki.wesnoth.org/CompilingWesnothOnWindows, but without the boost files, i compiled them on my own.

[Anonymissimus]

I have such crashes as well. Not sure whether it's the cache or the save_index or both. Deleting the cache regularly is a good idea as well. Perhaps there's some I/O bug in upstream (boost) code. You can try experimenting with other boost versions.

BfW has a structural long-term lack of windows developers and I'm tired of doing more than build system maintenance.

[Pentarctagon]

I've been compiling with Code::Blocks following the instructions here, and have never experienced this problem.

[Anonymissimus]

I've been compiling with Code::Blocks following the instructions here, and have never experienced this problem.

Yes, MinGw and Linux are apparently not affected.
However, it is likely that such kind of a problem is caused by undefined behavior somewhere, which is probably undefined for any kind of system, it's just not noticeable on all of them.

[gfgtdf]

well, good to know im not the only one without that problem.

EDIT2:
it seemes like my proposed fix causes another error sometimes, so i deleted it from this post.

EDIT:

I'm afraid there are zero devs using MSVC 2010 (me 2008) but I assume those are small fixes anyway ?

i deleted the msvc2010 fixes from my pull request as requested, but ye i just renamed HELP_INDEX and TOKEN_TYPE because they were already defined in some windows headers wich were included for some reasons.

[Anonymissimus]

As for the badbit etc issue, yes, you can talk to mordante about it, he's in charge, de facto. However, does wesnoth actually use the cache when restarting the debugger when you "fix" it ? When wesnoth launches a second time, it should (I think) read all of the cache files which were written during the previous launch and skip the preprocessing step for all wml which was loaded from the cache. Since launching wesboth under the VC debugger is so slow this would be a great improvement of course.
As for the compile fixes, yes, renaming (but be sure it's actually an unintended collision just by chance) something and making conversions explicit are very unintrusive.

[gfgtdf]

i did start wesnoth under the debugger but in release mode, so it wasnt that slow.

i tested without the fix and it crashend , then with the fix and it didnt carsh, and then again withut the fix and it did crash.

at your request i tested again with deleting the cache before both starts and got the same result.

[Anonymissimus]

i did start wesnoth under the debugger but in release mode, so it wasnt that slow.

Then you aren't under the debugger at all, you're just in release mode. The debugger displays pure nonsense to you and tricks you.
Only the debug mode makes sense (debug in MSVC, not in wesnoth, you should enable that additionally though). The release debug etc are also not great, it's only slightly faster but retrieved info is much worse.

[gfgtdf]

i dont need detailed debug information to determiene weather it crashes or not. and i am fully aware of the qualitiy of the infomration i get if i debug in release mode, and if i think that information cannot help me i'll compile it again in debug mode.

plus i have't noticed any bad lack of speed when i attach the debugger in release mode.