bonjour,
j'utilise actuellement la SDL2. Je viens de m'y mettre.
Je sais lier les librairies vu que j'utilisais déjà la version 1.2.
Le problème est qu'après avoir lu les tuto de lazy foo, qui fonctionnent très bien en c++, une fois reformaté et compilé en c j'ai un problème avec la SDL_Init.
Voici ce que me renvoie le débogueur :
(gdb) s
76 if( SDL_Init( SDL_INIT_VIDEO ) < 0 )
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x3) at malloc.c:2966
2966 malloc.c: Aucun fichier ou dossier de ce type.
Est-ce que quelqu'un aurait une idée de ce qu'il peut se passer?
cordialement
# Corruption mémoire
Posté par gorbal . Évalué à 2.
Ceci est dû à une corruption de la zone mémoire où est gérée les allocations mémoires (malloc/free).
Donc quand SDL_Init appelle free il va tomber sur une adresse corrompue => segmentation fault.
Il y a donc avant l'appel de SDL_Init, probablement un débordement de buffer sur une zone allouée par un malloc.
[^] # Re: Corruption mémoire
Posté par moi1392 . Évalué à 4.
J'ai pas compris pourquoi tu as été moissé, ta réponse est tout à fait pertinente et c'est très probable que ce soit la bonne.
Une façon simple de vérifier cela est de mettre ton sdl_init en tout premier dans ton main, à priori il devrait passer.
Ensuite reste à trouver la corruption mémoire, si tu n'y arrives pas en lisant ton code, des outils comme valgrind ou asan peuvent grandement t'aider.
[^] # Re: Corruption mémoire
Posté par gorbal . Évalué à 3.
Un exemple pour reproduire le problème:
# pas de corruption mémoire
Posté par gunsailor . Évalué à 1.
Et non, j'aurais dû le préciser par ailleurs.
J'appelle mon SDL_Init en tout début de code.
J'ai juste déclaré quelques variables avant en les initialisant soit à NULL soit à 0.
Je ne vois vraiment pas d'où vient le problème!
Surtout que, comme je le répète, j'ai seulement modifié un code c++ en code c sans toucher à l'organisation des fonctions…
C'est à n'y rien comprendre.
[^] # Re: pas de corruption mémoire
Posté par Amiralgaby . Évalué à 3.
Ensuite on test, et on trouvera
Amiralgaby#1847
[^] # Re: pas de corruption mémoire
Posté par moi1392 . Évalué à 2.
tu as l'initialisation des variables statiques/globales avant l'appel de main, ton code peut donc créer des soucis avant main.
Comme dit plus haut, si tu veux qu'on t'aide à trouver le problème, il nous faut le code (meme une version très simplifiée ou tu vires quasiment tout)
Sinon, on peut juste te donner des pistes et des moyens pour te débrouiller par toi meme.
Tu as fais un run valgrind ? tu as quoi comme résultat ?
# Ça sent une incompatibilité binaire
Posté par David Demelier (site web personnel) . Évalué à 2.
Ça me parait très bizarre comme problème. Ton système est à jour ? tu es sous quelle distribution ?
Tu utilises bien la SDL 2 fournie par ton système ? pas installée à la main ou autre ?
git is great because linus did it, mercurial is better because he didn't
# paquage sdl2 de stretch
Posté par gunsailor . Évalué à 1.
oui j'utilise la version de ma distribution.
J'ai utilisé valgrind -v sans plus de résultats.
Quant à gdb, maintenant il m'indique pour SDL_Init:
Je n'ai plus la même erreur sans rien avoir touché.
ET POURTANT, lorsque je vire la quasi totalité de mon code pour nelaisser que ma fonction d'initialisation, SDL_Init se comporte à ravir…
Je vous refile la totalité de mon code, je n'arrive pas à le formater pour qu'il rende dans les balises:
meric pour votre retour. à bientôt!
[^] # Re: paquage sdl2 de stretch
Posté par Crag . Évalué à 2.
Renomme la fonction close() en Xclose(), par exemple et ça marchera.
Ca doit clasher avec la fonction close(2), je suppose ? Il faudra demander à plus expert que moi.
[^] # Re: paquet sdl2 de stretch
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Je vois le même
SIGSEGV
sur 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
close
est défini dans l'exécutable.close
étant (également) un appel système fréquemment utilisé (plus haut, danslibdbus
), boum.Debian Consultant @ DEBAMAX
[^] # Re: paquet sdl2 de stretch
Posté par Crag . Évalué à 1.
Ah oui ! J'ai essayé sur une stretch comme l'auteur original.
Un strace me donne shutdown(2) comme dernière fonction appelée. Donc Si cette fonction a besoin d'appeler close() cela appelerait en fait la version redéfinie en fait ?
# ça marche
Posté par gunsailor . Évalué à 2.
ouai!! merci les gars.
à+
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.