Journal Mplayer + vidéo Windows = crash noyau

Posté par  (site web personnel) .
Étiquettes : aucune
0
21
juin
2004
Bonjour,

J'aimerais votre avis sur un problème qui m'embête bien. J'ai une Mandrake 10 avec un noyau 2.4.25 (-2 ou -5). Quand je lis une vidéo avec mplayer appelant une DLL Windows, le process est figé. Pire, tout process qui essaie d'accéder à ce process là (la commande "ps aux" par exemple, ou alors un "cat /dev/1234/cmdline") est figée elle aussi (ce qui implique que je ne peux pas connaitre le status de mon process).
Le seul moyen de rebooter est avec la commande magique alt-sys-b (ou le bouton reset), après quoi j'ai le droit à de fabuleux checkdisks (d'ailleurs au reboot le système me demande de faire à la main des fsck.reiserfs --rebuild-tree).
Je n'ai pas le problème avec la série précédente de noyau 2.4. J'ai cherché sur google en vain.
La dernière ligne que montre un "strace" est un "mmap2" sur la DLL Windows.

Que feriez-vous à ma place ? Comment agir de manière constructive ? C'est plutôt grave qu'un utilisateur non-privilégié puisse mettre en rade le système !

  • # DLLTools

    Posté par  . Évalué à 3.

    Il me semble que mplayer utilise DLLTool. P'tet qu'une mise à jour pourrais corriger ton problème. (sil n'y a que les codecs DLL qui ne marchent pas, c'est une piste)

    • [^] # Re: DLLTools

      Posté par  (site web personnel) . Évalué à 5.

      Ce qui m'inquiète ce n'est pas tant le plantage de mplayer, mais plutôt le fait qu'un processus utilisateur puisse mettre en déroute le système.
      Troll: si ça se passait sous Windows, on verrait des gens dire "ouais, c'est nul c'est un système mal fichu, vu que ce est un système propriétaire fermé ce n'est pas étonnant !

  • # carte graphique

    Posté par  . Évalué à 1.

    et ta carte graphique, elle marche bien ? jamais eu de pb similaire avec ?

  • # FORUM !

    Posté par  . Évalué à 2.

    > Que feriez-vous à ma place ?

    A ta place, je posterai ça sur les forums. Il y en a un pour Mandrake sur linuxfr :
    http://linuxfr.org/forums/14/(...)

    Merci de votre attention.

  • # Bug noyau ?

    Posté par  . Évalué à 3.

    Elle se trouve sur quel filesystem, ta lib ?
    Parce que mmap est un appel système bien connu, mais mmap2, même s'il est similaire, est:

    1) Spécifique à Linux
    2) Assez récent (depuis le noyau 2.3.31)

    Si en plus, cela bloque les processus complètement indépendants mais qui se réfèrent à ton processus (probablement via /proc), je dirais qu'il y a 9 chances sur 10 que mmap2 soit instable et réagisse mal à travers un filesystem exporté.

    Essaie déjà de déplacer ta DLL Windows sur ton disque local et de t'arranger pour que mplayer aille la chercher à cet endroit, cela devrait probablement résoudre le problème temporairement. Si elle s'y trouvait déjà, essaie au contraire de la déplacer vers une partition FAT ou EXT2. Ensuite, si tes recherches sur Google ne donnent rien, envoie un patch ou soumet un rapport de bug ... et tiens-nous au courant :-)

    Bon courage.

    • [^] # Re: Bug noyau ?

      Posté par  (site web personnel) . Évalué à 2.

      Elle se trouve dans /usr/lib/win32, sur une partition reiserfs (elle vient d'un paquet PLF). Pour le rapport de bug, je l'envoie du coté de Mandrake, ou alors il y a un endroit spécifique au noyau ?
      Bon, allez encore un petit test et quelques "fsck.reiserfs --rebuild-tree" :-(

    • [^] # Re: Bug noyau ?

      Posté par  (site web personnel) . Évalué à 2.

      tu as vérifié que le syscall mmap n'est pas émulé avec mmap2 et potentiellement visible comme un mmap2 dans strace ?

  • # 2.4 -> 2.6

    Posté par  . Évalué à 2.

    J'ai rencontré les mêmes problèmes, qui ont disparu lorsque je suis passé au noyau 2.6.
    Peut-être Mandrake a-t-elle intégré au noyau 2.4 des patch qui posent problème dans ce cas précis. À noter que le problème s'était également posé avec wine (toujours lié à des dll windows donc). Peut-être des patch de sécurité qui bloquaient le code windows ...

    • [^] # Re: 2.4 -> 2.6

      Posté par  . Évalué à 1.

      > toujours lié à des dll windows donc

      Il y a le même "problème" avec execshield. C'est un "faux" problème car execsheild peut-être désactivé par programme :
      # execstack -q /usr/bin/mplayer
      X /usr/bin/mplayer

      Pour un programme "normal" :
      # execstack /bin/ls
      - /bin/ls

      execshield peut aussi être désactivé lors de la phase de link mais j'ai oublié comment. Normalement au build de mplayer c'est fait automatiquement.

      • [^] # Re: 2.4 -> 2.6

        Posté par  (site web personnel) . Évalué à 2.

        J'ai essayé, et ce n'est pas ça. En lisant la FAQ de mplayer, j'ai lu que ce problème pouvait mener à un segfault, pas à un problème noyau.

  • # meuh

    Posté par  (site web personnel) . Évalué à 5.

    le process est figé. Pire, tout process qui essaie d'accéder à ce process là [..] est figée elle aussi

    Ca sent le D-state ça : le disk-state à savoir l'attente du processus du résultat d'une E/S disque. Ça arrive sur bug ou "feature"[1] du kernel. Pour ton cas, c'est curieux, est-ce que l'utilisation des dll windows nécessite un module kernel spécifique ? Ça ne doit pas être le cas je suppose, si c'est bien cela c'est probablement un bug du kernel. Essaie de mettre à jour ton kernel ?

    Le seul moyen de rebooter est avec la commande magique alt-sys-b (ou le bouton reset), après quoi j'ai le droit à de fabuleux checkdisks

    Avant Alt-SysRq-B, tappe Alt-SysRq-S et Alt-SysRq-U (plusieurs fois chacun, ça ne réagit pas toujours en une fois) : le S permet de s-ynchronser les disques (flusher les buffers d'ecriture sur disque) et U de u-mounter les partitions (en fait ça les remonte en read-only). Ça te permettra d'éviter toute corruption sur les disques.


    [1] un montage NFS par défaut est "hard" c'est à dire que toute attente réseau sur une entrée-sortie est complètement bloquante pour le processus (D-state donc) afin de simuler au plus près une partition montée localement ; ça peut être emmerdant si le serveur NFS tombe en rade, si on souhaite que les processus qui ouvrent des fichiers sur les volumes NFS se mangent des EIO plutôt qu'ils soient bloqués jusqu'au retour hypothétique du serveur NFS, monter avec l'option "soft"

    • [^] # Re: meuh

      Posté par  (site web personnel) . Évalué à 2.

      Essaie de mettre à jour ton kernel ?
      C'est le dernier dispo chez Mandrake.

      Alt-SysRq-U
      Je n'avais pas fait celui-là.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.