Ça veut dire quoi « un crash » ? L'OOM tue le process ? Il y a un segfault ? Un abort() ? …
Si une fuite est suspectée, plotter top/ps/proc est effectivement un bon début. Si tu plottes aussi /proc/$pid/maps tu peux commencer à voir plus précisement ce qui fuite à l'intérieur du process (probablement le tas).
S'il s'agit bien d'une fuite sur le tas, il y a plusieurs approches. Si Valgrind est une option, c'est sans doute le moyen le plus rapide de trouver la source du problème mais selon le programme concerné, ça n'est pas forcément faisable.
Une alternative est d'instrumenter le programme en hookant ou wrappant malloc/free « manuellement ».
Une autre approche assez barbare mais qui fonctionne parfois fort bien est d'attacher un debugger (ou dumper un core) et d'examiner des bouts de mémoire plus ou moins au hasard jusqu'à reconnaitre un motif évident.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
"Aucun fichier ou dossier de ce type" c'est strerror(ENOENT) (je suppose ; j'ai pas de locale fr installée) qui est retourné par execve() parce que a shared library needed for file or interpreter cannot be found.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
De ce que j'ai compris, le site a été fermé suite à la demande d'Oracle mais il n'y a pas eu d'attaque en justice formelle ni de publication de la raison pour laquelle ils ont fait la demande.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Une fois que ça marche, tu peux essayer avec ton noyal customisé. Si tu coinces, tu peux essayer de bissecter les options qui diffèrent entre ton noyau et celui de la distro.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
D'après ce que tu racontes, on a l'impression que tu as un mplayer qui se met en état D et n'en sort pas. Ça serait bien de commencer par vérifier sur quoi il bloque exactement. Selon le noyau, tu dois pouvoir obtenir un backtrace au niveau kernel via /proc/$pid/stack ou sysrq-t. Une fois que tu as confirmé que c'est Samba (et non le driver de la carte réseau, le device de swap ou des neutrinos), tu peux essayer d'obtenir une capture réseau (en commençant à capturer avant que le problème n'aparaisse) avec tcpdump par exemple. Après il s'agit de regarder à quel moment ça coince exactement et de déterminer si le problème est au niveau serveur ou client. Une fois cela fait, tu peux commencer à lire le code correspondant pour essayer de fixer le bug.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je sais qu'il existe kdump et kexec mais je n'ai encore jamais mis en œuvre ces mécanismes.
Bah il serait temps. Il est aussi possible que tu trouves des indices dans les logs kernels s'ils ont eu le temps d'être écrit sur le disque.
D'un autre côté, s'il s'agit effectivement de bugs du driver nvidia, même si tu diagnostiques exactement le problème, ça risque de ne pas t'avancer à grand chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ben, disons que c'est dans la même veine qu'écrire sur 2 membres d'une union à la suite: ça marche, mais ça laisse présumer du meilleur… ou du pire.
Je ne suis pas d'accord. Cette histoire d'union est injustifiable. Les asserts sur les valeurs de retour dans le code de test me semble tout à fait valable. On pourrait faire mieux en définissant son propre assert qui ne soit pas désactivable avec NDEBUG et qui va printfer des infos pertinentes avant de faire rater le test mais utiliser assert(3) me semble tout à fait acceptable et requiert d'écrire/maintenir le minimum de code.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est dommage que le ton de l'article ne soit pas un peu plus mesuré
D'un autre côté si tu viens chercher de l'objectif modéré dans un journal DLFP taggué coup_de_geule, tu n'es pas forcément au meilleur endroit.
ZeroMQ est utilisé à grande échelle par certaines entreprises
Je réitère donc mon opinion initiale à ce sujet : hahaha.
t'es tu intéressé aux branches 3.0 et 3.1 ?
Non. Le premier paquet maintenu que j'ai trouvé était 2.1.9 et le site web recommande 3.2.
[…] 𝆺𝅥𝅯 ton univers impitoyable ♩ […]
C'est beau mais inutilisable.
J'ai bien fait de pas m'y intéresser donc.
Il y a peut-être un compromis à trouver entre trop d'ouverture et la dictature ?
Certes. Et zmq ne l'a visiblement pas trouvé.
Je te trouve quand même très vocal sur un sujet aussi épineux alors que tu reconnais ne pas l'avoir vraiment suivi.
On m'a demandé mon avis, je le donne. Il m'arrive de me documenter sur l'histoire des projets qui m'intéressent mais zmq n'est pas un projet qui m'intéresse. J'ai juste eu à travailler avec et j'espère que le message est bien passé que je trouve que c'est de la merde.
Après les gens qui ont un avis différent et plus ou moins informé peuvent le donner en commentaire, dans un autre journal ou à la terrasse de leur café préféré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
ni Steam ni Spotify ne devraient être décrits comme "une solution de DRM".
D'accord, appelons les des solutions de vente en ligne basées sur des logiciels privateurs incluant des dispositifs numérique des restrictions promouvant un monde de surveillance orwellien et allant à l'encontre de la notion de partage. C'est un peu plus long par contre.
À titre personnel, j'aimerai savoir si tu as une bonne raison d'associer la législation allemande et la possibilité de créer des comptes sans passer par un identifiant Facebook ?
< AC> Krunch, HA HA you tried to use zmq rcs
< AC> Krunch, and you looked at the current code
< AC> Krunch, zmq 3 is doomed.
< AC> Krunch, they have a new policy for contributions
< AC> Krunch, they have people reviewing merge request and checking that they follow rules
< AC> Krunch, those rules exclude things "the code builds"
< AC> *like
< AC> Krunch, $company actually submitted a patch that didn't build by mistake, and it got in
< Krunch> AC: i look forward to your comments in that journal
< AC> Krunch, nope :)
< Krunch> ok, i'll just copy/paste what you said earlier
< AC> Krunch, please don't
< Krunch> what you said is pertinent and i don't feel like paraphrasing; write up that comment yourself or i'll anonymise+paste
< AC> Krunch, if you remove any reference to my employer or myself, feel free :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ça dépend de ce que tu appelles « mode optimisé ». Tu peux avoir -O4 et -UNDEBUG.
Mais dans ce cas de toute façon c'est des tests. J'espère bien qu'ils sont pas compilés avec -DNDEBUG (et de fait, ils le sont pas quand on fait un "make check" puisqu'il y en a qui abort()ent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# idées
Posté par Krunch (site web personnel) . En réponse au message Monitorer la consomation de ressource d'un process. Évalué à 2.
Ça veut dire quoi « un crash » ? L'OOM tue le process ? Il y a un segfault ? Un abort() ? …
Si une fuite est suspectée, plotter top/ps/proc est effectivement un bon début. Si tu plottes aussi /proc/$pid/maps tu peux commencer à voir plus précisement ce qui fuite à l'intérieur du process (probablement le tas).
S'il s'agit bien d'une fuite sur le tas, il y a plusieurs approches. Si Valgrind est une option, c'est sans doute le moyen le plus rapide de trouver la source du problème mais selon le programme concerné, ça n'est pas forcément faisable.
Une alternative est d'instrumenter le programme en hookant ou wrappant malloc/free « manuellement ».
Une autre approche assez barbare mais qui fonctionne parfois fort bien est d'attacher un debugger (ou dumper un core) et d'examiner des bouts de mémoire plus ou moins au hasard jusqu'à reconnaitre un motif évident.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# /proc/sys/vm/
Posté par Krunch (site web personnel) . En réponse au message Cache limité à 6G. Évalué à 4.
Va lire /usr/src/linux/Documentation/sysctl/vm.txt
Après, en examinant la valeur de chacun de ces sysctl, la raison devrait devenir évidente.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # RTFM
Posté par Krunch (site web personnel) . En réponse au message impossible d'éxecuter un fichier. Évalué à 4.
"Aucun fichier ou dossier de ce type" c'est strerror(ENOENT) (je suppose ; j'ai pas de locale fr installée) qui est retourné par execve() parce que a shared library needed for file or interpreter cannot be found.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: WeSunSolve
Posté par Krunch (site web personnel) . En réponse au journal SunWizard.NET n'est (presque) plus. Évalué à 2.
De ce que j'ai compris, le site a été fermé suite à la demande d'Oracle mais il n'y a pas eu d'attaque en justice formelle ni de publication de la raison pour laquelle ils ont fait la demande.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Deuxième PC?
Posté par Krunch (site web personnel) . En réponse au message Comment connaître l'origine d'un Kernel Panic depuis le mode graphique ?. Évalué à 2.
Commence par voir si tu arrives à dumper quelque chose avec le kernel fourni par la distribution en suivant les instructions de la distribution : http://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes#Step_1:_Configuring_Kdump
Une fois que ça marche, tu peux essayer avec ton noyal customisé. Si tu coinces, tu peux essayer de bissecter les options qui diffèrent entre ton noyau et celui de la distro.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# WeSunSolve
Posté par Krunch (site web personnel) . En réponse au journal SunWizard.NET n'est (presque) plus. Évalué à 5.
Deux mois après que WeSunSolve soit fermé sur la demande d'Oracle donc…
http://wesunsolve.net/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: backtrace or it didn't happen
Posté par Krunch (site web personnel) . En réponse au message samba kernel lock up. Évalué à 2.
gdb c'est pour l'userland. Ça risque de pas beaucoup aider ici.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Deuxième PC?
Posté par Krunch (site web personnel) . En réponse au message Comment connaître l'origine d'un Kernel Panic depuis le mode graphique ?. Évalué à 2.
C'est bien pour ça qu'il suggère de les écrire sur le port série (qui a de grandes chances d'être opérationel au moment du panic).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# backtrace or it didn't happen
Posté par Krunch (site web personnel) . En réponse au message samba kernel lock up. Évalué à 3.
D'après ce que tu racontes, on a l'impression que tu as un mplayer qui se met en état D et n'en sort pas. Ça serait bien de commencer par vérifier sur quoi il bloque exactement. Selon le noyau, tu dois pouvoir obtenir un backtrace au niveau kernel via /proc/$pid/stack ou sysrq-t. Une fois que tu as confirmé que c'est Samba (et non le driver de la carte réseau, le device de swap ou des neutrinos), tu peux essayer d'obtenir une capture réseau (en commençant à capturer avant que le problème n'aparaisse) avec tcpdump par exemple. Après il s'agit de regarder à quel moment ça coince exactement et de déterminer si le problème est au niveau serveur ou client. Une fois cela fait, tu peux commencer à lire le code correspondant pour essayer de fixer le bug.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# vmcore or it didn't happen
Posté par Krunch (site web personnel) . En réponse au message Comment connaître l'origine d'un Kernel Panic depuis le mode graphique ?. Évalué à 4.
Bah il serait temps. Il est aussi possible que tu trouves des indices dans les logs kernels s'ils ont eu le temps d'être écrit sur le disque.
D'un autre côté, s'il s'agit effectivement de bugs du driver nvidia, même si tu diagnostiques exactement le problème, ça risque de ne pas t'avancer à grand chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 3.
Je ne suis pas d'accord. Cette histoire d'union est injustifiable. Les asserts sur les valeurs de retour dans le code de test me semble tout à fait valable. On pourrait faire mieux en définissant son propre assert qui ne soit pas désactivable avec NDEBUG et qui va printfer des infos pertinentes avant de faire rater le test mais utiliser assert(3) me semble tout à fait acceptable et requiert d'écrire/maintenir le minimum de code.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dommage...
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 4.
D'un autre côté si tu viens chercher de l'objectif modéré dans un journal DLFP taggué coup_de_geule, tu n'es pas forcément au meilleur endroit.
Je réitère donc mon opinion initiale à ce sujet : hahaha.
Non. Le premier paquet maintenu que j'ai trouvé était 2.1.9 et le site web recommande 3.2.
J'ai bien fait de pas m'y intéresser donc.
Certes. Et zmq ne l'a visiblement pas trouvé.
On m'a demandé mon avis, je le donne. Il m'arrive de me documenter sur l'histoire des projets qui m'intéressent mais zmq n'est pas un projet qui m'intéresse. J'ai juste eu à travailler avec et j'espère que le message est bien passé que je trouve que c'est de la merde.
Après les gens qui ont un avis différent et plus ou moins informé peuvent le donner en commentaire, dans un autre journal ou à la terrasse de leur café préféré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Publication de la décision
Posté par Krunch (site web personnel) . En réponse au journal Enfin !!!!. Évalué à 3.
L'article du blog du dit avocat : http://www.cuifavocats.com/Double-condamnation-de-SAMSUNG-la
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ça tombe sur toi par hasard, tous les trolls open source m'énervent aujourd'hui
Posté par Krunch (site web personnel) . En réponse à la dépêche Les avancées des jeux pour GNU/Linux au mois d’octobre. Évalué à 7.
D'accord, appelons les des solutions de vente en ligne basées sur des logiciels privateurs incluant des dispositifs numérique des restrictions promouvant un monde de surveillance orwellien et allant à l'encontre de la notion de partage. C'est un peu plus long par contre.
Je vais juste laisser ça ici : http://www.wired.com/wiredenterprise/2012/11/cisco-vp-vows/
N'y voyez aucun rapport.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Mr X témoigne
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 10.
Pour les tests, je vois vraiment pas le problème. Ces asserts sont dans le code des tests, pas le code du produit lui même.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 2.
Ça dépend de ce que tu appelles « mode optimisé ». Tu peux avoir -O4 et -UNDEBUG.
Mais dans ce cas de toute façon c'est des tests. J'espère bien qu'ils sont pas compilés avec -DNDEBUG (et de fait, ils le sont pas quand on fait un "make check" puisqu'il y en a qui abort()ent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: M'enfin !
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 3.
http://www.jwz.org/doc/cadt.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: M'enfin !
Posté par Krunch (site web personnel) . En réponse au journal ZeroMQ et les mangoustes. Évalué à 4.
Le premier article c'est http://www.joelonsoftware.com/items/2003/10/13.html
Le second est évident pour n'importe qui ayant passé plus de 5 minutes dans les sources du noyal.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 4.
Un peu trop long pour un commentaire : https://linuxfr.org/users/krunch/journaux/zeromq-et-les-mangoustes
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 1.
Hahaha.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hello World concurrentiel
Posté par Krunch (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #45. Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# One operating system to rule them all
Posté par Krunch (site web personnel) . En réponse au journal Half-life 3 sera sous linux. UNIQUEMENT SOUS LINUX !. Évalué à 4.
http://openbsd.org/lyrics.html#52
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mon avis
Posté par Krunch (site web personnel) . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 3.
J'ai rien suivi mais je ne trouverais pas moral d'emprisonner quelqu'un qui n'a pas eu un procés en bonne et dûe forme.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.