The International Simutrans Forum

Development => Patches & Projects => Incorporated Patches and Solved Bug Reports => Topic started by: prissi on October 27, 2013, 09:55:13 PM

Title: Heap corruption in simloadingscreen every 10th time or so
Post by: prissi on October 27, 2013, 09:55:13 PM
Maybe there is something wrong with the event system. Backtrace suggest the error happens inside windows. Was this valgrinded recently?
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: Markohs on October 27, 2013, 11:27:30 PM
well, that code does delete events, might we be deleting events that we shoudn't?
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: Dwachs on October 28, 2013, 06:34:09 AM
Can you post the backtrace? Does this happen with any savegame or only with specific ones?

I use valgrind frequently, no errors in simloadingscreen reported ever.
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: prissi on October 28, 2013, 09:15:42 AM
It does happen in MSVC which just said the backtrace was triggered inside window. Unfourtunately this can happen also when malloc/free fails. MingW did not show this, but then I do not use it regularily. It does not crash regularely.

Best chances for a crash is to start with simutrans in the background, then bring to front with the click on the pakselector to the correct pak. Then in one out of five times it will crash.

I though too about deleting an event while it is processed, but I could not imagine a path that could lead to that. I will play around with dr_memory
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: prissi on October 28, 2013, 11:04:31 AM
With Dr.Memory a kanal (river) has a zero welt pointer when called by calc_bild() but not in debugger ?!?

But it gets worse, now I cannot even create a new map, since the exit_perlin gives an error.
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: Markohs on October 28, 2013, 11:20:06 AM
I can't see anything wrong on how events are handled in simloadingscreen, the even is created there and deleted if there is a need to (not queued).

My guess is some of the last patches messed something with the memory allocation, can it be the new karte_t as a global patch?
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: Markohs on October 28, 2013, 11:33:23 AM
I was able to get the crash too, the heap is corrupted somehow. As a last resort we'll have to compile previous versions until we find wich is the patch that's corrupting the heap.
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: prissi on October 28, 2013, 01:11:43 PM
it is 6866, the fix for the ground water tiles which causes trouble ...
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: Markohs on October 28, 2013, 02:01:34 PM
While we are at this, is it really complicated taking all the perlin stuff outside from simworld.cc to utils/perlin.cc or something like that?

Just a suggestion, ofc.
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: prissi on October 28, 2013, 02:13:11 PM
Most of it is already in simtools. I thin the stuff which needed to know the dimensions of the map is left there for speed. (And because it is map threaded like season change, rotation and so on.)
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: kierongreen on October 28, 2013, 03:10:44 PM
Possibly a problem with rivers detecting shorelines after the fix.
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: prissi on October 28, 2013, 03:30:38 PM
I fixed it, water_hgts was accessed with x and y coordinates of grid_hgts, so there was plenty of overflow. I hope I fixed the relevant areas.

EDIT:
I am not 100% sure I understand the purpose of water_hgts array. The comment is not so clarifying. Does it cache the grundwasser level of the current tile to do the flooding?
Title: Re: Heap corruption in simloadingscreen every 10th time or so
Post by: kierongreen on October 28, 2013, 11:13:53 PM
water_hgts stores water level for each tile. When this is water this stores height of sea/lake. When tile is land this should be set to the lowest possible water level (i.e. grundwasser-4). Previously it was set to grundwasser which then caused problems when lowering tiles.