Really, I simply do want to know if it still happens with DEP off:Kaks wrote:While you still have my eternal gratitude (for another few days at least) for discovering why windows sometimes really don't like timers, the random doom mongering really puzzles me.
1) this might give a workaround for troubled OOliteers while the bug is tracked down
2) that could very well indicate that something has been deleted and still is accessed (most probably a timer, but I also can imagine this with other bugs like deleting textures and then trying to access them)
OOlite, for me, is now ROCK STABLE. I know there are ways to crash it, but really, the current patching of scripts seems to have solved things for me. I'm also very glad that the multithreading has improved so much in the recent months...really, oolite is just great and I would not spend so much time on it if it weren't!
I already suggested that with a slight modification:Kaks wrote:If you've already got a patch that would neatly stop Oolite from clashing with DEP, I for one would be very interested to hear about it. One option we have - of course - is to remove timers altogether from the js implementation, so no OXPs can use this very much accident prone feature. It would kill a few very much liked OXPs though.
Remove timers from JS, but give an oolite interface to register for timer events. This way Oolite will always know when the source using the timer has been deleted and can kill off the timer itself. That also would allow to use fewer "real" timers which can help (at least with MFC).
My development system does have an XP 64 original, but I can't use that for running gdb as the development environment won't run under 64 bit Windows OS - and I still would require much help because somehow my debug builds don't give the expected details yet and gdb is also not a tool that I ever used outside oolite. My experience is with VisualStudio and C++...Kaks wrote:Of course we're hampered by the fact none of the developers have got XP 64 bit, which of course seems to behave slightly differently to either the more common XP (32 bits) or Vista 64 bits.
I thought I also wrote that already: The problem was that when I did quit that game the destruction sequence of object was badly chosen, thus some parts were deleted and still trying to execute. When there's no code in that can crash itself, DEP still will notice itKaks wrote:Somewhere else you told us that another game (the one you are developing for a selected group of friends) was running foul of DEP, and you managed to solve that issue.
That's why I said that turning ON DEP is a good way to find bugs which otherwise go unnoticed, but that it can be very helpful for people having trouble to switch it off (until the situation has been fixed).Screet
Here is the end of the log file:
