Okay I tried this with the latest download (pretty sure I downloaded the right one. The version number is the same, but libbyond.so MD5 was 9ff32c1f607b3e92bc659bdedbca07df )

Here is the trace, but its mostly the same:
https://hastebin.com/raw/lisojixota

I don't have valgrind output for this 511.1384 (2) version, but I did get some good output on the previous version. Just before crashing it read 4 bytes (a pointer I presume) from a block that had been free()'d. That seems consistent with your hypothesis.
Unfortunately still problematic. I can duplicate the same issue with new libbyond in Windows and Linux both.
Here is a valgrinded result. Includes memory map at bottom for symbol alignment. This one is pretty comprehensive since valgrind was running, DD crashed with sigsegv, etc.

https://hastebin.com/raw/xamedemesu
Well crap. I guess I'll have to keep researching this for a 1385 fix. I think the new logic is better, but I suppose it's possible it's hitting some kind of fringe case I didn't predict.
Here's a byond crash log while testing another technique of applying decals. I think you said at one point that setting overlays to a list calls different procedure from adding to it? I believe this proc is doing the whole...
overlays = overlays.Copy() + list_of_images

https://hastebin.com/raw/luwopufibu
Finally, my crash was fixed. (Looking at last post nvm I guess xD)

A quickfix that worked for me was to check if the changed object (The one you're changing the over/underlays of) still existed.


(Also that means, unfortunately that the fix you threw in for me did not work Lummox, but good to know its fixed now!)
Page: 1 2 3