Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e7fffc in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
(gdb) bt
#0 0x00007ffff7e7fffc in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#1 0x000055555555565e in close ()
#2 0x00007ffff7038bd4 in _dbus_close () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007ffff7036bef in _dbus_file_get_contents () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007ffff7032fb1 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x00007ffff703a2ff in _dbus_read_local_machine_uuid () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#6 0x00007ffff70331e7 in _dbus_get_local_machine_uuid_encoded () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#7 0x00007ffff70276bf in dbus_try_get_local_machine_id () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#8 0x00007ffff7027774 in dbus_get_local_machine_id () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#9 0x00007ffff7f228ed in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x00007ffff7f2301b in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x00007ffff7f2251f in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x00007ffff7f073ff in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x00007ffff7f0e467 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#14 0x00007ffff7ee8db3 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#15 0x00007ffff7e41f47 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#16 0x00005555555553e9 in init ()
#17 0x0000555555555703 in main ()
et une fois que le close() du fichier principal est renommé en autre chose, ça se passe beaucoup mieux. Sans cela, on a :
kibi@tokyo:/tmp$ gcc -O0 foo.c -lSDL2 -lSDL2_image -lSDL2_ttf && nm -D a.out | grep close
0000000000001646 T close
et le symbole close est défini dans l'exécutable. close étant (également) un appel système fréquemment utilisé (plus haut, dans libdbus), boum.
[^] # Re: paquet sdl2 de stretch
Posté par Cyril Brulebois (site web personnel) . En réponse au message erreur de segmentation sur SDL_Init. Évalué à 2.
Je vois le même
SIGSEGVsur bullseye :et une fois que le
close()du fichier principal est renommé en autre chose, ça se passe beaucoup mieux. Sans cela, on a :et le symbole
closeest défini dans l'exécutable.closeétant (également) un appel système fréquemment utilisé (plus haut, danslibdbus), boum.Debian Consultant @ DEBAMAX