Forum Programmation.c [kernel 2.6.12] => 2.6.11 -> 2.6.12 => Seg fault

Posté par  .
Étiquettes : aucune
0
11
juil.
2005
Bonjour,

Je travail sur un programme personnel qui fonctionnait très bien avant ma mise à jour kernel du 2.6.11 au 2.6.12. Depuis, j'ai une erreur de segmentation. Cette erreur disparait lorsque je repasse sur mon 2.6.11. J'ai réussit à isoler ce problème dans un petit programme C/C++. Je recherche des personnes pouvant compiler, tester ce programme pour me dire quelle est leur version du noyau et si il y a eu une erreur de segmentation ou non. (Note: utilisation ou non des NPTL). De plus si vous avez une idée pouvant expliquer ce comportement ...

Code:

#include
#include <unistd.h>
#include <pthread.h>
#include <expect.h>
#include <stdlib.h>
#include

using namespace std;

static char *username;
static char *prompt;

void error(const char *message) {
cerr << "Error: " << message << endl;
exit(EXIT_FAILURE);
}

void *console_task(void *) {
int fd;
FILE *cnx = exp_popen("bash");
if (cnx == 0)
error("bash connexion failed");
string prompt_regexp(".*" + string(username) + "@.* $");
exp_fexpectl(cnx, exp_regexp, prompt_regexp.c_str(), 1, exp_end);
string sleep_command = "sleep 10\n";
fwrite(sleep_command.c_str(), sizeof(char), sleep_command.length(), cnx);

exp_fexpectl(cnx, exp_regexp, prompt, 1, exp_end);
//prompt_regexp.c_str(), 1, exp_end);
return 0;
}

int main(int argc, char **argv) {
username = getenv("USER");
string sprompt(".*" + string(username) + "@.* $");
prompt = (char *)malloc(sprompt.length() + 1 * sizeof(char *));
strcpy(prompt, sprompt.c_str());
cout << prompt << endl;
if (argc > 1)
console_task(NULL);
else {
pthread_t task;

pthread_create(&task, NULL, console_task, NULL);
pthread_join(task, NULL);
}
return EXIT_SUCCESS;
}

Pour compiler : g++ -o segfault -lexpect5.42 -lpthread segfault.c
(il sera peut ête nécessaire d'adapter la version de la libexpect).

Merci de votre aide,
  • # utilisation de strace

    Posté par  . Évalué à 1.

    tu peut peut etre utiliser strace pour voir vraiment ou se produit le segfault, normalement fourni avec les outils de debogage de ta distribution

    http://www.liacs.nl/~wichert/strace/(...)
    • [^] # Re: utilisation de strace

      Posté par  . Évalué à 1.

      Merci, cependant, peux-tu compiler et exécuter ce programme sur machine et me dire celà plante ou pas ainsi que quelle est la version de ton noyau ?
      • [^] # Re: utilisation de strace

        Posté par  . Évalué à 1.

        malheureusement je suis au taf et sous windows.... :-( donc je ne peut pas trop le compiler
        je vais néanmoins essayer de trouver une linux box dans le coin, ou j'essayerais ce soir
        • [^] # Re: utilisation de strace

          Posté par  . Évalué à 1.

          j'en profite aussi pour demander quels sont les fichiers inclus qui n'apparaissent pas dans ton code (surement nettoyer par templeet)

          merci d'avance
          • [^] # Re: utilisation de strace

            Posté par  . Évalué à 1.

            Ce sont les fichiers string et iostream (c++)


            Mon investigation avance, j'ai suivit ton conseil concernant strace.
            En fait sur mon 2.6.12 un appel à futex échoue alors qu'il fonctionne sur mon 2.6.11. Cet appel serait à la source d'une erreur de rétablissement de contexte du thread => segmentation fault.

            Mais la question essentiel est de savoir si cela ne viens pas de mon système. Ainsi, j'espère que tu pourras tester cela ce soir.

            Merci pour tout
            • [^] # Re: utilisation de strace

              Posté par  . Évalué à 2.

              j'ai essayé ton prog avec plusieurs noyaux + libexpect5.43 + tcl8.4.11 + gcc3.4.4:
              en plus, vu que j'avais la flemme d'attendre 10sec, j'ai mis sleep 5 et la le programme n'a pas planté avec les noyaux 2.6.12

              noyau 2.6.12 (+patchset gentoo-r4)
              -> sleep 10-> segmentation fault
              -> sleep 5 -> pas de segmentation fault

              noyau 2.6.11(+patchset gentoo-r11)
              -> sleep 10 -> pas de segfault
              -> sleep 5 -> pas de segfault non plus

              noyau 2.6.12 + nitro patches
              -> sleep 10 -> segfault
              -> sleep 5 -> pas de segfault

              je n'ai pas d'autres noyaux sous la main donc voila voila, en espérant que cela t'aide a déterminer ton probleme
              • [^] # Re: utilisation de strace

                Posté par  . Évalué à 1.

                j'ai oublié: utilisation des NPTL :-)
              • [^] # Re: utilisation de strace

                Posté par  . Évalué à 1.

                Cela m'aide pas mal.
                Il est normal qu'avec 5 sec le programme fonctionne en fait car c'est le timeout interne par défaut est de cet ordre là. En tout cas ça pose aussi problème sur ta machine.
                Le seul point négatif c'est que tu utilise les noyaux gentoo comme moi ... ce qui je le reconnais est une excellente idée !!! ;) mais n'est pas terrible pour la vérification du bug.

                Merci beaucoup en tout cas.
  • # gdb...

    Posté par  . Évalué à 2.

    est ton ami, avec une petite interface graphique si tu prefere (DDD).

    De maniere generale ne pas tester toutes les valeurs retours des fonctions n'est pas une bonne habitude.

    prompt = (char *)malloc(sprompt.length() + 1 * sizeof(char *));
    strcpy(prompt, sprompt.c_str());

    ce transforme en cas d'erreur en une tentative d'ecriture a l'adresse 0.
    ce qui causerait un segfault.
    Electric fence est aussi ton ami pour les fuites de memoires
    • [^] # Re: gdb...

      Posté par  . Évalué à 2.

      Le problème de seg fault ne vient pas de là. Je tiens à préciser que ce programme est effectivement sale, aucuns contrôles ...
      Cependant, ce n'est qu'un programme écris vite fait pour mettre en avant un bug à la fin de l'exécution de exp_fexpctl sur ma machine.
      Ce que je souhaite c'est savoir si ce bug se produit sur vos machines ...
      (je connais bien gdb et en ce qui concerne les fuites mémoires j'ai une certaine préférence pour valgrind)

Suivre le flux des commentaires

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