Unexplained segfault when resizing the window

[Bigfoot71]

I also had crashes with löve 11.3 on Linux Mint 20.3
It also seemed memory or graphics related:
https://love2d.org/forums/viewtopic.php ... 75#p250375
It was just drawing a simple tilemap multiple times (splitscreen game) but it would crash if the tilemap array was larger than 100x100 or so. Or when drawing more than certain number of canvases.
After updating to löve 11.4 it did not crash anymore, even with much larger tilemap arrays.

Thank you for this answer, it is indeed likely that there is a link because in this game I also use large tilemaps and also several canvases at times especially for transition effects, however I also had the problem with 11.4.

I know in any case that the problem does not come directly from an error on my part, the game runs very well on other machines and the crash only occurs when I use several programs at the same time as the game. I was still able to slightly reduce the vram consumption of the game with some tricks in case it came from there but the problem is still present.

[GVovkiv]

Just to be sure:
Could you try flatpak love https://flathub.org/apps/details/org.love2d.love2d version and see if that makes any difference?

[Bigfoot71]

Just to be sure:
Could you try flatpak love https://flathub.org/apps/details/org.love2d.love2d version and see if that makes any difference?

Good idea unfortunately the problem is still present.
However I just realized something, the game only crashes when I resize the window "a lot" in one go. If I first resize it very slightly by a few pixels there is a slight freeze then I can finally resize it as I want without any crash. Really very strange bug.

[GVovkiv]

Just to be sure:
Could you try flatpak love https://flathub.org/apps/details/org.love2d.love2d version and see if that makes any difference?

Good idea unfortunately the problem is still present.
However I just realized something, the game only crashes when I resize the window "a lot" in one go. If I first resize it very slightly by a few pixels there is a slight freeze then I can finally resize it as I want without any crash. Really very strange bug.

Well, as i was trying to explain, the faster you resize window, the more stuff will be in memory until you stop resizing and system will be able clear it.
Try this: make function that resize window to any size and run it for every intervel, like 1 second
1 second should be enough to clear memory from older surface of program so more memory will be available so you should don't expirience any crashes.
And then switch this interval to something like 0.1 seconds. In this case, system wouldn't be able to clear memory in time so at some point program will get segfault because of no available memory.

If this will act as i explained, then... Well, you need more memory
Or more swap?

[Bigfoot71]

Well, as i was trying to explain, the faster you resize window, the more stuff will be in memory until you stop resizing and system will be able clear it.
Try this: make function that resize window to any size and run it for every intervel, like 1 second
1 second should be enough to clear memory from older surface of program so more memory will be available so you should don't expirience any crashes.
And then switch this interval to something like 0.1 seconds. In this case, system wouldn't be able to clear memory in time so at some point program will get segfault because of no available memory.

If this will act as i explained, then... Well, you need more memory
Or more swap?

I understood it but I still find the behavior quite strange, the ram is not saturated, increasing the stack temporarily did not change anything, the vram is no longer, I just tried again and it is busy at ~180mb/256 when the bug appeared.

Unless it comes from a deeper problem of allocation function call counts and use of this memory (I don't really believe in it) I can't find a 100% convincing explanation for the instant.

I'll try when I have more time to increase the swap size or check how busy it is and report back.

I tried a small animation to show how the problem occurs:


Edit: I must have misread your proposal with translator and misunderstood (what I understood seemed weird to me...), I finally did this with setMode:

Code: Select all

    t = t + dt
    if t>=.1 then
        lw.setMode(math.random(GW), math.random(GH), {
            resizable = true
        })
        t=0
    end

No matter the limit, 1 second or 0.1 second I have no crash.
Only when I resize with the mouse the game is likely to crash.

[Bigfoot71]

Following the progress of my project with many changes as well as a big update of my PC (including that of the kernel) from today I no longer noticed this problem without too much explanation. So I don't know if it's due to changes in my project or to this update but everything is back to normal on my device, so much the better!

[GVovkiv]

Following the progress of my project with many changes as well as a big update of my PC (including that of the kernel) from today I no longer noticed this problem without too much explanation. So I don't know if it's due to changes in my project or to this update but everything is back to normal on my device, so much the better!

Good for you, then. Probably was something with hardware + software related
It would be still nice to understand why that happens

[Bigfoot71]

I restarted my PC with my previous kernel and the problem does not occur either so it was not from that. It's going to be complicated to understand now, I didn't keep a backup of my code from that moment...

The problem does not occur strangely with Valgrind, maybe I should have tried with GDB, who knows, a little too late...

Thank you for the help anyway!