2010-10-25 3 views
2

Je joue avec X-development. J'ai un proto-WM de base qui fonctionne pendant un certain temps et produit ensuite ces erreurs après un temps assez aléatoire.Comment interpréter le rapport de traçage de programme X?

[modifier]

Locking assertion failure. Backtrace: 
#0 /usr/lib/libxcb-xlib.so.0 [0x7f71dcf9a9ac] 
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f71dcf9aa54] 
#2 /usr/lib/libX11.so.6 [0x7f71ddefe340] 
#3 /usr/lib/libX11.so.6(XAllocColor+0xc1) [0x7f71ddedada1] 
#4 /home/mais/code/simplewin/bin/Debug/simplewin [0x408e0b] 
#5 /home/mais/code/simplewin/bin/Debug/simplewin [0x409062] 
#6 /home/mais/code/simplewin/bin/Debug/simplewin [0x407a9d] 
#7 /home/mais/code/simplewin/bin/Debug/simplewin [0x406c6d] 
#8 /home/mais/code/simplewin/bin/Debug/simplewin [0x402734] 
#9 /home/mais/code/simplewin/bin/Debug/simplewin [0x407e37] 
#10 /home/mais/code/simplewin/bin/Debug/simplewin [0x407304] 
#11 /home/mais/code/simplewin/bin/Debug/simplewin [0x407335] 
#12 /lib/libpthread.so.0 [0x7f71ddc9afc7] 
#13 /lib/libc.so.6(clone+0x6d) [0x7f71dd26a59d] 
Locking assertion failure. Backtrace: 
#0 /usr/lib/libxcb-xlib.so.0 [0x7f71dcf9a9ac] 
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x17) [0x7f71dcf9ab17] 
#2 /usr/lib/libX11.so.6 [0x7f71ddefe420] 
#3 /usr/lib/libX11.so.6 [0x7f71ddefeb5b] 
#4 /usr/lib/libX11.so.6 [0x7f71ddefeeb5] 
#5 /usr/lib/libX11.so.6(XNextEvent+0x68) [0x7f71ddee5898] 
#6 /home/mais/code/simplewin/bin/Debug/simplewin [0x404bc2] 
#7 /lib/libpthread.so.0 [0x7f71ddc9afc7] 
#8 /lib/libc.so.6(clone+0x6d) [0x7f71dd26a59d] 

Il ressemble à une sorte de bug de synchronisation dans mon application; la plupart du temps, les ressources utilisées sont libérées dans le bon ordre, mais à un moment donné, cela devient confus et les erreurs se produisent.
Comment interpréter ce qui précède pour trouver l'emplacement/la cause des erreurs?

+0

Pourquoi n'utilisez-vous pas gdb pour trouver ce qui s'est mal passé? – ssegvic

+0

@ssegvic: pouvez-vous mettre dans une réponse des pointeurs sur ce que je pourrais faire en utilisant gdb pour essayer d'isoler l'erreur (s)? Ma modification ci-dessus était le résultat d'une utilisation superficielle, mais la sortie backtrace ne reste pas la même. Toutes les idées que vous avez seront les bienvenues. – slashmais

+0

Je faisais référence à ce que je considère comme l'itération de débogage habituelle: i) construire l'exécutable avec les informations de débogage (-g, NDEBUG indéfini), ii) lancer le programme depuis gdb (gdb a.out, run), iii) reproduire le crash , iv) examine la source (backtrace, haut, bas). Je veux dire que vous pourriez sûrement trouver le code source correspondant aux lignes de vos backtraces en utilisant objdump et vos amis, mais employer gdb devrait être une option plus confortable. HTX – ssegvic

Répondre

1

1) construire votre programme avec debug symbold (sur gcc, passer l'option -g)
2) activer les fichiers core, et une fois que votre application se bloque, ouvrez-le dans gdb avec le fichier de base, et vérifiez la backtrace
3) votre application est-elle multithread et utilise xlib? Si c'est le cas, vous devez activer l'accès multi-thread aux fonctions xlib.
4) installez ddd, et exécutez votre application en utilisant cela (ddd est un interface graphique pour le débogueur linux gdb)

+0

thanx, va lui donner un bash et rapporter ici. Juste besoin de prendre le temps ... – slashmais

Questions connexes