Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Scope de variable et segmentation fault !

5 réponses
Avatar
Yves Martin
Bonjour,

Un autre problème "tordu" dans mon script. J'ai simplifié mon code pour le
présenter mais je comprends mal ce qui se passe.

Voici un extrait de code qui "fonctionne" chez moi:

## Main process
sub main {
## Load configuration as a hash
tie %config, 'Config::IniFiles', ( -file => $options{"config"} );

my $file = $config{Main}{Fifo} || "decision";
&logmsg("Start as server, producer on " . $file);
my $producer = new Thread(\&producer, $file);
}

Pour faire "propre", j'ai déplacé qq lignes dans une fonction:

sub server(\%) {
my %config = @_;

my $file = $config{Main}{Fifo} || "decision";
&logmsg("Start as server, producer on " . $file);
my $producer = new Thread(\&producer, $file);
}

## Main process
sub main {
## Load configuration as a hash
tie %config, 'Config::IniFiles', ( -file => $options{"config"} );

&server(%config);
}

Et le résultat est terrifiant !

Thu Jan 13 11:37:14 2005: Start as server, producer on decision
Segmentation fault (core dumped)

J'ai l'intuition du problème, et je remplace la ligne:
my $producer = new Thread(\&producer, "decision");

Et cela fonctionne à nouveau mais échoue plus loin sur le même schéma
d'utilisation de variable.

Comment se fait-il que print (utilisé dans logmsg) soit capable de m'afficher
le contenu de la variable $file mais que son usage dans un autre package (ici
Thread) soit impossible au point de faire un segfault ?

Est-ce que cela vient du 'tie %config' ? D'un problème de scope de variable ?
Merci d'avance
--
Yves Martin

5 réponses

Avatar
Paul Gaborit
À (at) Thu, 13 Jan 2005 11:58:35 +0100,
Yves Martin écrivait (wrote):
Est-ce que cela vient du 'tie %config' ? D'un problème de scope de variable ?


Faites les tests vous-même en utilisant la bonne veille stratégie "diviser
pour mieux régner" :

- tester avec tie sans thread.
- tester avec thread mais sans tie.

Un 'segv' de Perl ne me semble possible que sur du code externe (mais vous
semblez ne pas en utiliser) ou sur du code récemment intégré à Perl... donc
plutôt un problème dû aux threads.

Par ailleurs, pour passer un objet (surtout si il utilise 'tie' ou si il peut
être gros) à une fonction, utilisez plutôt une référence qu'une copie de
l'objet lui-même.


--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>

Avatar
Yves Martin
Paul Gaborit writes:

À (at) Thu, 13 Jan 2005 11:58:35 +0100,
Yves Martin écrivait (wrote):
Est-ce que cela vient du 'tie %config' ? D'un problème de scope de variable
?


Un 'segv' de Perl ne me semble possible que sur du code externe (mais vous
semblez ne pas en utiliser) ou sur du code récemment intégré à Perl... donc
plutôt un problème dû aux threads.


Justement, cela me semble plus qu'étrange.

Par ailleurs, pour passer un objet (surtout si il utilise 'tie' ou si il peut
être gros) à une fonction, utilisez plutôt une référence qu'une copie de
l'objet lui-même.


Dans mon cas l'objet qui pose problème est $file qui ne contient qu'un nom de
fichier. Son extraction du hash copié par passage en paramêtre ne pose aucun
problème car print l'affiche. Par contre son utilisation comme paramêtre de
new pour Thread ou IO::Socket::INET provoque le crash !?!

Je vais essayer d'extraire un cas test atomique que je pourrai soumettre ici.

Merci
--
Yves Martin


Avatar
Samuel Mouniée
Bonjour,

Est-ce que cela vient du 'tie %config' ? D'un problème de scope de variable
?


Un 'segv' de Perl ne me semble possible que sur du code externe (mais v ous
semblez ne pas en utiliser) ou sur du code récemment intégré à Perl... donc
plutôt un problème dû aux threads.


Justement, cela me semble plus qu'étrange.


rien d'étonnant au premier abord : votre code ne semble pas thread-safe.


Par ailleurs, pour passer un objet (surtout si il utilise 'tie' ou si i l peut
être gros) à une fonction, utilisez plutôt une référence qu'u ne copie de
l'objet lui-même.


Dans mon cas l'objet qui pose problème est $file qui ne contient qu'un nom de
fichier. Son extraction du hash copié par passage en paramêtre ne po se aucun
problème car print l'affiche. Par contre son utilisation comme param être de
new pour Thread ou IO::Socket::INET provoque le crash !?!

Je vais essayer d'extraire un cas test atomique que je pourrai soumettre ici.


il y a des informations sur plusieurs modules sur leur étanchéité au
threads dispo sur le CPAN . si cela se trouve outre votre code, le
module que vous utilisez pour gérer la conf ne l'est pas non plus.


.s'nuoM

--
+---- Samuel Mouniée
| o o | Moun's
----+ http://artdif.com/ - http://www.mouns.net/



Avatar
Yves Martin
Samuel Mouniée <usenet+ writes:

Bonjour,

Est-ce que cela vient du 'tie %config' ? D'un problème de scope de
variable ?


Un 'segv' de Perl ne me semble possible que sur du code externe (mais vous
semblez ne pas en utiliser) ou sur du code récemment intégré à
Perl... donc plutôt un problème dû aux threads.


Justement, cela me semble plus qu'étrange.


rien d'étonnant au premier abord : votre code ne semble pas thread-safe.


Je suis d'accord mais il ne l'est pas plus quand la partie de code incriminée
se trouve directement dans &main et pas dans une autre fonction dédiée.

Je n'ai pas réussi à reproduire le problème en créant un autre script plus
léger. Je laisse cela de côté pour l'instant et j'y reviendrai plus
tard. Entre temps j'aurai mis les lock où il faut, peut-être que cela
suffira...

Autre question générale, pourquoi Perl peut crasher comme cela sans rien dire
? Pour une machine virtuelle c'est dommage.

--
Yves Martin




Avatar
Paul Gaborit
À (at) Fri, 14 Jan 2005 14:21:58 +0100,
Yves Martin écrivait (wrote):
Autre question générale, pourquoi Perl peut crasher comme cela sans rien
dire ? Pour une machine virtuelle c'est dommage.


C'est même absolument anormal ! Vous avez donc trouvé un bug de perl.

Mais n'oubliez pas que le support des threads est toujours classé
expérimental. Ceci explique cela...

Si vous arrivez à faire un script simple qui exhibe le bug, vous pouvez
toujours faire un rapport aux développeurs.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>