XIO: fatal IO error 11
Oui, cette question a été posée avant, mais en lisant les réponses ne m'éclairer beaucoup.
J'ai écrit un programme en C qui tombe en panne après quelques jours d'utilisation. Un point important est qu'il ne génère PAS un fichier de base, même si tout est mis en place de sorte qu'il devrait (core_pattern, ulimit -c unlimited, etc. Je peux déclencher un core dump fine avec kill -SIGQUIT).
Les programmes largement les journaux de ce qu'il fait, mais il n'y a aucune allusion à propos de l'accident dans le journal.
Le seul message affiché à l'écrasement (ou avant?) est:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 2322 requests (2322 known processed) with 0 events remaining.
Donc deux questions:
- comment est-il possible pour un programme de crash (return $?=1) sans vidage de la mémoire.
- qu'est-ce que ce message d'erreur à propos et que puis-je faire ?
Système RedHat Enterprise 6.4
Edit:
J'ai réussi à forcer un vidage de la mémoire par appel abort() à l'intérieur d'un atexit() rappel:
(gdb) bt
#0 0x00bc8424 in __kernel_vsyscall ()
#1 0x0085a861 in raise () from /lib/libc.so.6
#2 0x0085c13a in abort () from /lib/libc.so.6
#3 0x0808f5cf in Unexpected () at MyCode.c:1378
#4 0x0085de9f in exit () from /lib/libc.so.6
#5 0x00c85701 in _XDefaultIOError () from /usr/lib/libX11.so.6
#6 0x00c85797 in _XIOError () from /usr/lib/libX11.so.6
#7 0x00c84055 in _XReply () from /usr/lib/libX11.so.6
#8 0x00c68b8f in XGetImage () from /usr/lib/libX11.so.6
#9 0x004fd6a7 in ?? () from /usr/local/lib/libcvi.so
#10 0x00478ad5 in ?? () from /usr/local/lib/libcvi.so
...
#29 0x001eed9d in ?? () from /usr/local/lib/libcvi.so
#30 0x001eee41 in RunUserInterface () from /usr/local/lib/libcvi.so
#31 0x0808fab4 in main (argc=2, argv=0xbfbdc984) at MyCode.c:1540
Quelqu'un peut m'éclairer à ce problème d'X11 ? libcvi.il n'est donc pas la mienne, seulement MyCode.c (LabWindows/CVI).
Modifier 2014-12-05:
Voici encore plus précis de la trace. Les choses ont vraiment arriver dans X11, mais je ne suis pas X11 programmeur, donc en regardant le code source de X à partir de la condition linestell moi seulement que le serveur X (?) est temporairement indisponible. Est-il possible de simplement dire de l'ignorer cette erreur si elle n'est que temporaire ?
#4 0x00965eaf in __run_exit_handlers (status=1) at exit.c:78
#5 exit (status=1) at exit.c:100
#6 0x00c356b1 in _XDefaultIOError (dpy=0x88aeb80) at XlibInt.c:1292
#7 0x00c35747 in _XIOError (dpy=0x88aeb80) at XlibInt.c:1498
#8 0x00c340a6 in _XReply (dpy=0x88aeb80, rep=0xbf82fa90, extra=0, discard=0) at xcb_io.c:708
#9 0x00c18c0f in XGetImage (dpy=0x88aeb80, d=27263845, x=0, y=0, width=60, height=20, plane_mask=4294967295, format=2) at GetImage.c:75
#10 0x005f46a7 in ?? () from /usr/local/lib/libcvi.so
Lignes correspondantes:
XlibInt.c: _XDefaultIOError()
1292: exit(1);
XlibInt.c: _XIOError
1498: _XDefaultIOError(dpy);
xcb_io.c: _XReply()
708: if(!reply) _XIOError(dpy);
GetImage.c: XGetImage()
74: if (_XReply (dpy, (xReply *) &rep, 0, xFalse) == 0 || ...
/proc/<pid>/fd répertoire après qu'il a été exécuté peu de temps; voyez-vous une augmentation du nombre de liens là-dedans?Il prend habituellement plusieurs jours avant de planter, mais je vais être suivi de la situation. Quelques recherches sur google m'amènent à croire que c'est un Xinerama/NVidia multi-moniteur de problème non lié à mon application.
Retrait de Xinerama n'a pas aidé. Je reçois toujours ces incidents sans vidage de la mémoire. N'importe quel outil je peux utiliser pour le retrouver ?
Notez que le cœur de décharges sont désactivés par défaut. Vous devez l'activer, par exemple en cours d'exécution
ulimit -c unlimited dans la même coque que vous lancez l'application à partir de (ou de le faire par programmation à partir de l'application avec un setrlimit(RLIMIT_CORE, ... ) à l'appel)Oui, je connais ulimit, mais ça n'aide pas. Il semble que le programme se ferme par l'intermédiaire d'un appel à exit(0) dans une bibliothèque. Je viens de découvrir que je peux l'attraper avec atexit(). J'ai placé un appel d'abort() à l'intérieur et maintenant je suis en attente pour elle de quitter encore une fois (quelques jours).
OriginalL'auteur dargaud | 2014-09-11
Vous devez vous connecter pour publier un commentaire.
OK, j'ai enfin trouvé la cause (grâce à quelqu'un de chez National Instruments), un meilleur diagnostic et une solution de contournement.
Le bug est dans de nombreuses versions de libxcb et est un 32 bits compteur de roulement de problème que l'on a connu depuis quelques années: https://bugs.freedesktop.org/show_bug.cgi?id=71338
Pas toutes les versions de libxcb sont affectés libxcb-1.9-5 a, libxcb-1.5-1 ne fait pas. À partir de la liste des bugs, OS 64-bits ne devraient pas être affectées, mais j'ai réussi à le lancer sur au moins une version.
Qui m'amène à un meilleur diagnostic. Le programme suivant va se planter en moins de 15 minutes sur les bibliothèques (mieux que l'ensemble de la semaine, il fallait auparavant):
Et une dernière chose, au-dessus de la prog compilé et exécuté sur un système 64 bits fonctionne très bien, compilé et exécuté sur un vieux système 32 bits fonctionne aussi très bien, mais si je transfert la version 32 bits pour le système 64 bits, il se bloque après quelques minutes.
OriginalL'auteur dargaud
Je viens d'avoir un programme qui a agi exactement comme ça, avec exactement le même message d'erreur. Je m'attends à ce que le compteur d'erreur de processus 2^32 événements avant de s'écraser.
Le programme a été structuré de telle sorte qu'un thread a un X connexion au X fil de sorte qu'il peut envoyer des messages à l'X fil de mise à jour de la fenêtre.
À la fin, j'ai tracé le problème à un endroit où la fonction d'envoi d'événements à la fenêtre pour redessiner il a été appelé par plusieurs threads, sans un mutex sur elle, et puisque X à la même X connexion n'est pas réentrant, s'est écrasé avec cette erreur exacte. Mettre dans un mutex sur la fonction et aucun problème depuis.
OriginalL'auteur camelccc