Long pause when debugging a program Raylib or SDL on Linux

[lilliemarck]

When stepping over, or setting a breakpoint after InitWindow the debugger pauses for about 15-30 seconds, depending on which computer I use. The dlv process consumes 5 GB of memory during the pause.

Same thing happens with programs written in SDL or when writing a simple Cgo binding to Raylib myself. Both these libraries and my code do the runtime.LockOSThread() thing.

The problem is partially fixed by debugging with Goland but only if I use the Flatpak install. With Goland Flatpak the debugger freezes the first run and then only occasionally. Unfortunately I can only run my SDL programs like this but Raylib, which defaults to using Wayland, doesn't work at all unless I switch to the .tar.gz istall. I had other issues with VS Code too so I am not surprised Flatpak is not suitable for development, except for it doesn't freeze as often...

I am guessing it has something to do with lots of shared libraries being loaded.

go version go1.23.4 linux/amd64
 
Delve Debugger
Version: 1.24.0
Build: $Id: 2d55e4d30150e3fc68e64357e21293d7920fc1f1 $

main.go

package main

import rl "github.com/gen2brain/raylib-go/raylib"

func main() {
	println("No problem on this line")

	rl.InitWindow(800, 450, "raylib [core] example - basic window")
	defer rl.CloseWindow()

	rl.SetTargetFPS(60)

	for !rl.WindowShouldClose() {
		rl.BeginDrawing()
		rl.ClearBackground(rl.RayWhite)
		rl.DrawText("Congrats! You created your first window!", 190, 200, 20, rl.LightGray)
		rl.EndDrawing()
	}
}

go.mod

module basic_window

go 1.23.4

require github.com/gen2brain/raylib-go/raylib v0.0.0-20250109172833-6dbba4f81a9b

require (
	github.com/ebitengine/purego v0.7.1 // indirect
	golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842 // indirect
	golang.org/x/sys v0.20.0 // indirect
)

[lilliemarck]

I guess an example with Cgo is better because it doesn't need the binding libraries. Just install the raylib dev package dnf install raylib-devel.

package main

import (
	"runtime"
	"unsafe"
)

/*
#include <raylib.h>
#include <stdlib.h>
#cgo LDFLAGS: -lraylib
*/
import "C"

func InitWindow(width, height int, title string) {
	ctitle := C.CString(title)
	defer C.free(unsafe.Pointer(ctitle))
	C.InitWindow((C.int)(width), (C.int)(height), ctitle)
}

func main() {
	runtime.LockOSThread()
	println("Before InitWindow")
	InitWindow(800, 450, "raylib [core] example - basic window")
	println("After InitWindow")
}

[aarzilli]

I think it's just debuginfod-find downloading symbols, as a temporary workaround you can put a shell script called debuginfod-find in your PATH, before the real one, containing just:

#!/bin/bash
exit 1

[lilliemarck]

Thanks, it works! I figured it was something with downloading debug symbols but forgot mention it. When writing C or C++ it also takes time but only once.

[aarzilli]

You're right, even after it has downloaded the debug symbols it is still slow on the very first stop after the libraries are loaded. This is because the symbols for llvm are pretty large (over 1GB), this is going to be complicated to fix.

[lilliemarck]

How come there is no noticeable delay when debugging C with gdb?

[aarzilli]

I imagine they are doing less preprocessing, possibly none.