http://bugs.winehq.org/show_bug.cgi?id=11231
--- Comment #11 from Alexander Dorofeyev alexd4@inbox.lv 2008-01-25 11:02:34 ---
I remember in the past (in a different context) already observing different behaviour between using or not WINEDEBUG. How comes? What must one consider in order not to interfere with program execution?
Well that's pretty normal with memory/heap corruption cases (worst kind of bugs IMO). Sometimes it crashes in one place, sometimes in another, at times it can even sort of successfully run. It depends on all kinds of things and it often crashes in a completely different place instead of where the real damage has been done. There's little that can be done to ensure consistent behavior, but AFAIK WINEDEBUG=+heap *may* help, because it enforces some additional checks here and there, so if the heap is becoming corrupted, at least with some luck it may detect it earlier (closer to the actual spot where this happens).
Regarding test_arb_vs_offset_limit - there are known problems with it, see bug#11210. IIRC the reporter is Intel driver developer. So, if it crashes there, it may be a different problem from other memory corruptions.
I have not explicitly set it. make tests creates a .wine from scratch if not already present so wine uses all default settings.
Test aside, what was used for 2D ddraw games that crashed? Could it be that ddraw renderer was opengl?