That is to be expected. Every time a roboport is removed the game has to check each of the robots to see if any of them were going to charge at that roboport, or if any were going to station at it.

Unless you add a (double) linked list of robots to the roboports. Then you can just iterate over ...

Trust me, neither is necessary in this case. I provided a save file anyways, not because it's necessary but because it's an easy way to reproduce the crash like this:

Load the save, sync mods as needed. The save starts 6 seconds prior to warp. There is one chest with lots of stuff in it. Mentally ...

I'm playing the mod Warp Drive Machine currently and am experiencing some crashes - if they happen, it's always exactly when my ship get's teleported to/from space to a different location (which seems to be implemented by creating a new surface, moving the relevant ship tiles over to the new surface ...

Ok, since there is no other event like on_gui_disappeared or such, is there any way at all to figure out, that the gui that was visible before is now not visible any longer?
If not, can we please get a new event on_gui_disappeared which fires exactly once for each gui that disappears for whatever ...

control.lua that demonstrates this bug:

if global.bug_115401 == nil
then
global.bug_115401 = {}
global.bug_115401.open_gui_counter = 0
end

function update_gui(player)
if not global.bug_115401.gui
then
global.bug_115401.gui = player.gui.left.add{type="frame", name="bug_115401", direction ...

Part of a mod I'm working on is keeping track of the nesting level of opened GUIs. The principle of the code looks like this:

on_gui_opened: ++gui_open_counter;
on_gui_closed: --gui_open_counter;

The code works, however if I open a chest and then mine it, the GUI disappears (as it should) but the ...

I just run into this lockup again. Still using 1.1.100.

The saving process has terminated (zombie).

The main thread seems to be trying to read some status update from the saving process:

#0 __GI___libc_read (nbytes=4, buf=0x7ffe412bcc68, fd=94) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI ...