Game stop when rotate the camera continuously

[Ranran(retired)]

Hi. (´・ω・｀)
Rotating the camera continuously with this map always stops the game. It is a small size map for testing.
Open this saved game and click the map rotate button several times in succession.
This will always happen in this map even with the latest nightly builds, but for my own debug build this message was displayed.

[jamespetts]

I looked into this briefly earlier to-day. The problem appears to occur when removing co-ordinates to connected attractions in certain stops in order to rewrite them with the rotated co-ordinates. The actual failure occurs deep in a template class for a hashtable (where it interacts with a memory management system called "freelist") which is not a structure that I understand, as these are low level structures unchanged from Standard, so it is very difficult for me to understand what is happening and why this is occurring.

If this occurs only on some maps, this may have to be treated as a low priority issue for the present.

[prissi]

This error message means either that you are freeing something that was already freed or rather that something was freed which was overwritten with something larger. Freelist is just a faster way to alloc lots of chunk of identical memory size (i.e. trees). It saves a lot memory and is about 3x faster than malloc/free (or new/delete without freelist).

[DrSuperGood]

Is the freelist thread safe for both allocations and frees? One of the reasons malloc/new is usually so slow is thread safety.

[ACarlotti]

I think this was caused by modifying a hashtable while it was being iterated over. I've uploaded a fix for this.

I think the precise issue was caused when two consecutive entries in the hashtable were a coordinate and its rotation. This would mean that the element removed a few lines later in the line uint16 f_2 = connected_attractions.remove(k); was the same element that iter was now pointing to. If then latter element were the last element in the bag, then the next time iter were stepped it would run past the end of the bag before checking for equality with the end of the bag. The result is a buffer overread, with iter continuing to step through the rest of the memory until something breaks (all the while adding garbage data to k_list and f_list).

[Ranran(retired)]

I confirmed that this bug has been fixed.
@A.Carlotti -  Excellent work Thank you!