Finding the cause of random segfaults

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
grump
Party member
Posts: 536
Joined: Sat Jul 22, 2017 7:43 pm

Re: Finding the cause of random segfaults

Post by grump » Sat Jan 12, 2019 3:46 pm

pgimeno wrote:
Sat Jan 12, 2019 3:21 pm
No crash on my side. My version: libfreetype6:amd64 2.6.3-3.2 (the Debian package)
Huh. Same version as mine. Just checked on another machine with a newer freetype, no crash there either. Sigh.

Edit: I think the loadFont() function is the culprit here. Docs say not to deallocate the data given to FT_New_Memory_Face until FT_Done_Face is called. Since fontData is a local object, it is prone to premature garbage collection after the function returns (assuming the reference returned by getPointer is a weak reference). Making fontData global solves this issue; so I'm back to creating a reproducible example.

User avatar
pgimeno
Party member
Posts: 1531
Joined: Sun Oct 18, 2015 2:58 pm

Re: Finding the cause of random segfaults

Post by pgimeno » Sat Jan 12, 2019 4:04 pm

Not sure if that's the cause, but changing this:

Code: Select all

local function loadFont()
	local fontData = assert(love.filesystem.newFileData('zrnic rg.ttf'))
to this:

Code: Select all

local fontData
local function loadFont()
        fontData = assert(love.filesystem.newFileData('zrnic rg.ttf'))
(so that the FileData object is live during the rest of the execution) fixed it for me.

Edit: I edited before your post, by the way. I was getting crashes.
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories - portland (mobile orientation)
The MS-Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

grump
Party member
Posts: 536
Joined: Sat Jul 22, 2017 7:43 pm

Re: Finding the cause of random segfaults

Post by grump » Sat Jan 12, 2019 4:24 pm

I fixed this problem in the original code by keeping a reference to the FileData object around.

The issue did just mask the actual cause for my segfaults though. Now I'm back to getting random segfaults with no stack trace whatsoever, and the jit.off() switch that made me find this issue does not change a thing about it. Bummer, would've been nice.

User avatar
pgimeno
Party member
Posts: 1531
Joined: Sun Oct 18, 2015 2:58 pm

Re: Finding the cause of random segfaults

Post by pgimeno » Sat Jan 12, 2019 6:17 pm

Are there any more uses of getPointer()?

Anything besides FreeType that uses FFI?

Do you use threads?
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories - portland (mobile orientation)
The MS-Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

grump
Party member
Posts: 536
Joined: Sat Jul 22, 2017 7:43 pm

Re: Finding the cause of random segfaults

Post by grump » Sat Jan 12, 2019 7:14 pm

pgimeno wrote:
Sat Jan 12, 2019 6:17 pm
Are there any more uses of getPointer()?
No.
Anything besides FreeType that uses FFI?
Yes, an older version of moonblob, that makes heavy use of ffi for data conversion. It's on my list to be removed anyways. I'll see if it makes any difference. It's a real long shot, since it's used only intermittently, and completely separated from anything else.

That's about it. I'm using love-nuklear for the UI. It's a C Lua lib, not exactly ffi. The issues started to appear since I've upgraded the project (including love-nuklear) to 11.x.
Do you use threads?
No.

Post Reply

Who is online

Users browsing this forum: No registered users and 13 guests