Heap corruption in simloadingscreen every 10th time or so

[prissi]

Maybe there is something wrong with the event system. Backtrace suggest the error happens inside windows. Was this valgrinded recently?

[Markohs]

well, that code does delete events, might we be deleting events that we shoudn't?

[Dwachs]

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.

[prissi]

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

[prissi]

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.

[Markohs]

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?

[Markohs]

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.

[prissi]

it is 6866, the fix for the ground water tiles which causes trouble ...

[Markohs]

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.

[prissi]

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.)

[kierongreen]

Possibly a problem with rivers detecting shorelines after the fix.

[prissi]

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?

[kierongreen]

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.