Fvsinit32 segfault, semblerait en rapport avec mutex

Bonjour à tous,

Je poste mon soucis sans grand espoir, mais bon, sait-on jamais:
J'ai un bout de code (confidentiel, donc peux pas le poster) qui fait un appel à Fvsinit32 pour initialiser une structure avec les valeur null définis de la vue correspondante de cette manière:

Code:

---

Fvsinit32(structure, "nom_de_la_vue")

---

J'ai un segfault qui se pointe (pas tout le temps) dans cette portion de code. Quand j'analyse le core généré via dbx, la stack trace donne:

Code:

---

1 2 3 4 5 6

Segmentation fault in _e_mutex_lock at 0xd1398400 ($t1) 0xd1398400 (_e_mutex_lock+0x20) a81f003c lha r0,0x3c(r31) (dbx) where _e_mutex_lock() at 0xd1398400 _Finit_cache32() at 0xd1373d34 Fvsinit32() at 0xd1381330

---

Je me dis donc que c'est un problème de thread, j'ai cru comprendre que cette fonction n'était pas thread safe via ce lien:

Citation:

---

A thread in a multithreaded application may issue a call to Fvsinit() or Fvsinit32() while running in any context state, including TPINVALIDCONTEXT.

---

Le problème intervient uniquement lorsque nous sommes plusieurs à faire des requêtes sur le serveur (le segfault apparait sur le serveur).

Le segfault est tout le temps au même endroit (Fvsinit32), mais ne dépend pas du cheminement parcouru.

La plupart des appels à "Fvsinit32" passent sans soucis.

Donc à votre bon coeur, si vous avez des pistes ou avez connu des soucis avec ces fonctions......

Merci d'avance :).

Salut,

De manière générale, une erreur de segmentation survient lorsque tu essaye d'accéder à une adresse mémoire à laquelle tu n'aurais jamais du essayer d'accéder.

Le problème, c'est que cela peut soit être du à de mauvais paramère transmis à une des fonctions soit à une erreur dans ton propre code et qu'il nous sera plus ou moins impossible de t'aider si on n'a pas un minimum d'informations sur ton code :aie:

Je comprend très bien le besoin de confidentialité de ton code, mais te serait-il possible de nous donner un code minimum compilable suffisamment proche de ton code confidentiel qui reproduise le problème :question:

Sinon, dans l'ordre, je vérifierais tous les pointeurs :

• sont-ils initialisés à null :question:
• si tu dois fournir toi-meme l'espace mémoire requis, fais tu appel à l'allocation dynamique "en temps et en heure :question:
• si allocation dynamique, demande-t-elle une place "correcte et suffisante" :question:
• si ta bibliothèque attend un pointeur, est-ce qu'elle risque de gérer elle-même l'allocation dynamique de la mémoire :question:
• si oui, ne transmettrais-tu pas bêtement un pointeur sur une variable pour laquelle tu n'as pas eu recours à l'allocation dynamique :question:
• pourrais tu envisager d'utiliser des pointeurs intelligents :question:

Puis je m'intéresserais sans doute à mes tableaux et autres collections : n'essayes-tu pas d'accéder à des index hors bornes :question:

Enfin, je verrais si je peux "bétonner" le respect de la const-correctness pour tout le code auquel j'ai accès

Salut, merci de t'interesser à mon soucis :).

concernant le code, non il est trop spécifique donc je ne peux pas te fournir un exemple.

La struct que je passe en paramètre est allouée sur la pile juste avant l'appel de la fonction.

La vue est bien définie avant, dans tout les cas.
Comme vu dans le debuggueur, les pointeurs ne sont pas null, donc pas de soucis de ce coté là.

Le segfault semble être (comme je l'ai dis) sur une mutex (j'en déduis ça par le nom de la fonction). Sauf que je n'utilise pas cette mutex, elle semble interne à la lib oracle.

Puis concernant la reproductibilité, c'est justement là le soucis, on le reproduis très rarement et jamais au même endroit (entendre par la, la fonction parente est souvent différente).

Le seul point commun c'est que ce segfault intervient dans Fvsinit32 et toujours cette histoire de mutex.
Sachant que l'on passe plusieurs 100aine de fois sur ces fonctions sans que ça crash, puis d'un coup, sans prévenir, pof ça crash.

Concernant les pointeurs, on est sur qu'ils sont valables (on en utilise pas, tout est sur la pile à cet endroit). Les seuls pointeur existant au passage de la fonctions sont bien initialisés à null.

Les seules variable accessible lorsque l'on arrive dans Fvsinit32 est la structure passé en paramètre et la chaine de caractère. les vues étant enregistrées dans la biblio elle-même, nous ne les gérons pas.

Tu utilises une fonction non-thread-safe dans un contexte threadé, et tu constates des "crash random", y'a rien de surprenant et c'est typiquement du crash dû aux threads...
Je vois pas 36 solutions ni aucune magie possible : du mutex autour des appels à ces méthodes.

Ok, j'étais pas sur qu'elle soit non-thread-safe, on va essayer comme ça :).

Citation:

---

Envoyé par skeud

Salut, merci de t'interesser à mon soucis :).

concernant le code, non il est trop spécifique donc je ne peux pas te fournir un exemple.

La struct que je passe en paramètre est allouée sur la pile juste avant l'appel de la fonction.

La vue est bien définie avant, dans tout les cas.
Comme vu dans le debuggueur, les pointeurs ne sont pas null, donc pas de soucis de ce coté là.

Le segfault semble être (comme je l'ai dis) sur une mutex (j'en déduis ça par le nom de la fonction). Sauf que je n'utilise pas cette mutex, elle semble interne à la lib oracle.

---

Je dirais plutôt que c'est à cet endroit qu'apparait le problème...

Mais il faut savoir que, dés qu'il est question de pointeurs, le point où l'application crashe peut être très éloignée du point d'origine du problème.

Citation:

---

Puis concernant la reproductibilité, c'est justement là le soucis, on le reproduis très rarement et jamais au même endroit (entendre par la, la fonction parente est souvent différente).

Le seul point commun c'est que ce segfault intervient dans Fvsinit32 et toujours cette histoire de mutex.

Sachant que l'on passe plusieurs 100aine de fois sur ces fonctions sans que ça crash, puis d'un coup, sans prévenir, pof ça crash.

---

J'ai envie de dire que c'est bien la preuve que le problème n'est pas dans Fvsinit32...

Je pencherais volontiers pour un appel à delete sur un pointeur sans remettre ce pointeur à null ou pour une assertion faite par le développeur sur "ce qui sera fait par l'utilisateur" qui s'avère fausse à cause des habitudes de l'utilisateur :aie:

Dans un des projets sur lesquels j'ai travaillé, on utilisait également une base de donnée oracle et il y avait un "lock" mis sur toutes les données utilisées en modification. Mais les utilisateurs venaient d'un système basé sur des fichiers plats et avaient l'habitude de se demander l'un à l'autre "libère moi le lock sur tel fichier" pour y apporter des modifications. Habitude qu'ils ont gardé malgré la nouvelle application (celle que je développais, qui utilise une bdd oracle).

On nous a demandé de permettre la libération des données lockées. Les développeurs ayant pensé qu'il s'agissait simplement de supprimer le lock de données après plantage, on n'y a pas prêté attention. Mais les utilisateurs ont utilisé cette possibilité pour se donner les uns aux autres la possibilité de modifier certaines données communes. Chose que nous n'avions pas prévue :aie:

On a donc régulièrement eu des inconsistances dans la bdd et des plantages dus au fait que, lorsque l'utilisateur reprenait le lock qu'il venait de "preter à son collègue", les données n'étaient pas rechargées depuis la bdd.

Et comme il était clair pour les développeurs que ce n'était ni fait ni à faire, il nous a fallu très longtemps pour reproduire le bug et pour comprendre que notre assertion quant à l'utilisation était fausse :aie:

Ne serais-tu pas face à un cas similaire :question:

Citation:

---

Concernant les pointeurs, on est sur qu'ils sont valables (on en utilise pas, tout est sur la pile à cet endroit). Les seuls pointeur existant au passage de la fonctions sont bien initialisés à null.

---

Et les autres données créées "ailleurs" :question: Je serais surpris que tu n'utilises pas l'allocation dynamique de la mémoire à un endroit ou à un autre :aie:

Une fois que tu as appelé delete sur tes pointeurs, veilles tu bien à remettre tes pointeurs à null ou à supprimer la référence à ce pointeur de la (des) collections qui le contien(ne)t:question:

Citation:

---

Les seules variable accessible lorsque l'on arrive dans Fvsinit32 est la structure passé en paramètre et la chaine de caractère. les vues étant enregistrées dans la biblio elle-même, nous ne les gérons pas.

---

Il va falloir travailler avec des log afin de garder une trace de tout ce qui se fait entre le lancement de l'application et le moment du plantage, car l'origine du problème est "ailleurs" :aie:

On a justement effectué plus de test, et il s'avère que le serveur plante lorsqu'on rajoute une modification récente, sans cette modification, le serveur semble "stable" ie->on n'a pas de segfault.

L'ajout correspond à une nouvelle fonctionnalité copié collé sur les autres (recupération de donnée dans la bdd). Le fichier en question contient 30 000 ligne de code, et environ 500-600 fonctionnalité, toute identique à un détail près, la vue utilisé pour oracle.
J'ai effectué des vérification, et avant cette ajout, il n'y a pas de "membre commun" pour chacune des vues.

Mais depuis l'ajout de la nouvelle fonctionnalité, celle-ci récupère une vue comprenant une partie d'une autre vue. Or:
_ Le crash intervient lorsqu'on effectue une action avec cette nouvelle vue
_ Et en même temps, une action sur une ancienne fonctionnalité qui fait appel à une autre vue mais avec des données partagé avec la première.

Donc, notre piste est:
Comme les deux vue s'entrechoque et que le Fvsinit32 n'est pas protégé par une mutex, les deux vue essaye d'accéder aux même données en même temps, ce qui expliquerais les erreurs.

Concernant les pointeurs, on a un outil de statistique qui permet de connaitre les référence menant probablement à un segfault (pointeur non initialisé, pointeur free mais pas nuller ......). Donc concernant ce point, on est bon, c'est une certitude.

On va mettre en place les mutex autour de ces appels pour voir si ça corrige le soucis, je reviendrais poster le résultat.

Concernant l'utilisation utilisateur, on ne rentre pas dans ce cadre là, car on reproduit bien le scénario, avec plus ou moins de difficulté en fonction de la charge que l'on fixe sur le serveur.
Il faut reconnaitre que la probabilité de passer dans 2 fonction ne durant que quelques milliseconde en même temps avec 2 clients différents est proche de nulle, d'où la difficulté à trouvé la cause principale de ce problème.

Salut,

En C++ comme dans n'importe quel autre langage (dont SQL), les copier/coller sont une véritable galère :aie: N'y aurait-il pas intérêt à créer quelques "parties" de requètes que vous n'auriez "qu'à" concaténer de manière à créer les différentes vues :question:

Le code est historique donc il faut respecter les normes qui étaient mise en place avant qu'on arrive, en l’occurrence, les fonctions de ce fichier possède un nom en rapport avec la vue qu'elle appelle (c'est pas la création des vues, mais bien de l'utilisation dont on parle dans mon problème). Donc les copier/coller ne peuvent être évités :).

Citation:

---

Envoyé par skeud

Le code est historique donc il faut respecter les normes qui étaient mise en place avant qu'on arrive, en l’occurrence, les fonctions de ce fichier possède un nom en rapport avec la vue qu'elle appelle (c'est pas la création des vues, mais bien de l'utilisation dont on parle dans mon problème). Donc les copier/coller ne peuvent être évités :).

---

Alors, je ne vois plus qu'un solution : retirer toutes les nouvelles fonctionnalités (par rapport au dernier point qui fonctionnait sans problème s'entend) et les rajouter une à une jusqu'à trouver celle qui provoque le plantage.

Bien sur, il s'agira de veiller à respecter les dépendances pour ne pas essayer de remettre une fonctionnalité qui en nécessite une autre qui n'aura pas encore été testée à fond :aie: ;)