[NetBSD] Comportement étrange de fprintf()

Le
JKB
Bonjour à tous,

Je viens d'installer un NetBSD/amd64 dans une virtualbox pour tester
différentes choses (et ne pas bricoler mes machines de production).
J'ai recompilé un programme que j'utilise de longue date sur NetBSD
sans problème.

Le NetBSD en question n'est pas la dernière mouture : il s'agit d'un
5.1 avec noyau officiel.

Souci : le programme ne se lance pas.

Après bissection du code, je me suis rendu compte que le problème
était à l'intérieur d'un fprintf() :

if (fprintf(f_source, "MODE_INTERACTIF") < 0)
{
perror("fprintf");
return(EXIT_FAILURE);
}

Ce fprintf() me renvoit EINVAL (!). Naturellement, j'ai bien vérifié
les droits d'accès (de toute façon, même en root le problème est le
même). Le fichier en question est créé par :

if ((f_source = fopen(nom_fichier_temporaire, "w")) == NULL)
{

return(EXIT_FAILURE);
}

et la création du fichier se passe bien. La variable
nom_fichier_temporaire est une chaîne de caractères créée de toute
pièce en fonction d'une racine, du pid, du tid et d'un compteur.
Elle est correcte.

EINVAL semble provenir de l'appel write() sous-jacent à fprintf().
Dans la doc, je lis :

[EINVAL] The pointer associated with d was negative.
[EINVAL] The total length of the I/O is more than can be
expressed by the ssize_t return value.

Je ne vois pas trop comment je pourrais être dans l'un des deux cas.
Peut-être dans le premier, mais je ne vois pas comment je pourrais
influer sur le pointeur asocié au descripteur de fichiers

Une idée ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse
=> http://grincheux.de-charybde-en-scylla.fr
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #24874762
Le Tue, 16 Oct 2012 08:39:36 +0000 (UTC),
JKB
Bonjour à tous,

Je viens d'installer un NetBSD/amd64 dans une virtualbox pour tester
différentes choses (et ne pas bricoler mes machines de production).
J'ai recompilé un programme que j'utilise de longue date sur NetBSD
sans problème.

Le NetBSD en question n'est pas la dernière mouture : il s'agit d'un
5.1 avec noyau officiel.

Souci : le programme ne se lance pas.

Après bissection du code, je me suis rendu compte que le problème
était à l'intérieur d'un fprintf() :

if (fprintf(f_source, "MODE_INTERACTIFn") < 0)
{
perror("fprintf");
return(EXIT_FAILURE);
}

Ce fprintf() me renvoit EINVAL (!). Naturellement, j'ai bien vérifié
les droits d'accès (de toute façon, même en root le problème est le
même). Le fichier en question est créé par :

if ((f_source = fopen(nom_fichier_temporaire, "w")) == NULL)
{
...
return(EXIT_FAILURE);
}

et la création du fichier se passe bien. La variable
nom_fichier_temporaire est une chaîne de caractères créée de toute
pièce en fonction d'une racine, du pid, du tid et d'un compteur.
Elle est correcte.

EINVAL semble provenir de l'appel write() sous-jacent à fprintf().
Dans la doc, je lis :

[EINVAL] The pointer associated with d was negative.
[EINVAL] The total length of the I/O is more than can be
expressed by the ssize_t return value.

Je ne vois pas trop comment je pourrais être dans l'un des deux cas.
Peut-être dans le premier, mais je ne vois pas comment je pourrais
influer sur le pointeur asocié au descripteur de fichiers...

Une idée ?

JKB



Je viens de compiler strace pour voir si j'arrivais à avoir un peu
plus d'information, mais strace ne retourne aucun appel système (!).
Sur aucun programme d'ailleurs, ce qui est étrange. Pourtant la
liste des appels systèmes a bien été générée lors de la compilation
du paquet...

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Bruno Ducrot
Le #24875222
Bonjour,

On 16-10-2012, JKB wrote:
Le Tue, 16 Oct 2012 08:39:36 +0000 (UTC),
JKB
Bonjour à tous,

Je viens d'installer un NetBSD/amd64 dans une virtualbox pour tester
différentes choses (et ne pas bricoler mes machines de production).
J'ai recompilé un programme que j'utilise de longue date sur NetBSD
sans problème.

Le NetBSD en question n'est pas la dernière mouture : il s'agit d'un
5.1 avec noyau officiel.

Souci : le programme ne se lance pas.

Après bissection du code, je me suis rendu compte que le problème
était à l'intérieur d'un fprintf() :

if (fprintf(f_source, "MODE_INTERACTIFn") < 0)
{
perror("fprintf");
return(EXIT_FAILURE);
}

Ce fprintf() me renvoit EINVAL (!). Naturellement, j'ai bien vérifié
les droits d'accès (de toute façon, même en root le problème est le
même). Le fichier en question est créé par :

if ((f_source = fopen(nom_fichier_temporaire, "w")) == NULL)
{
...
return(EXIT_FAILURE);
}

et la création du fichier se passe bien. La variable
nom_fichier_temporaire est une chaîne de caractères créée de toute
pièce en fonction d'une racine, du pid, du tid et d'un compteur.
Elle est correcte.

EINVAL semble provenir de l'appel write() sous-jacent à fprintf().
Dans la doc, je lis :

[EINVAL] The pointer associated with d was negative.
[EINVAL] The total length of the I/O is more than can be
expressed by the ssize_t return value.

Je ne vois pas trop comment je pourrais être dans l'un des deux cas.
Peut-être dans le premier, mais je ne vois pas comment je pourrais
influer sur le pointeur asocié au descripteur de fichiers...

Une idée ?





Non, j'en suis désolé.


JKB



Je viens de compiler strace pour voir si j'arrivais à avoir un peu
plus d'information, mais strace ne retourne aucun appel système (!).
Sur aucun programme d'ailleurs, ce qui est étrange. Pourtant la
liste des appels systèmes a bien été générée lors de la compilation
du paquet...




Sous un BSD, j'ai plutôt tendance à utiliser le couple ktrace/kdump qui, détail
non négligeable, est intégré au système.

Peut-être auras tu plus de chance de voir où se situe le problème avec ce
couple ?

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
JKB
Le #24875252
Le 16 Oct 2012 12:45:21 GMT,
Bruno Ducrot
Bonjour,

On 16-10-2012, JKB wrote:
Le Tue, 16 Oct 2012 08:39:36 +0000 (UTC),
JKB
Bonjour à tous,

Je viens d'installer un NetBSD/amd64 dans une virtualbox pour tester
différentes choses (et ne pas bricoler mes machines de production).
J'ai recompilé un programme que j'utilise de longue date sur NetBSD
sans problème.

Le NetBSD en question n'est pas la dernière mouture : il s'agit d'un
5.1 avec noyau officiel.

Souci : le programme ne se lance pas.

Après bissection du code, je me suis rendu compte que le problème
était à l'intérieur d'un fprintf() :

if (fprintf(f_source, "MODE_INTERACTIFn") < 0)
{
perror("fprintf");
return(EXIT_FAILURE);
}

Ce fprintf() me renvoit EINVAL (!). Naturellement, j'ai bien vérifié
les droits d'accès (de toute façon, même en root le problème est le
même). Le fichier en question est créé par :

if ((f_source = fopen(nom_fichier_temporaire, "w")) == NULL)
{
...
return(EXIT_FAILURE);
}

et la création du fichier se passe bien. La variable
nom_fichier_temporaire est une chaîne de caractères créée de toute
pièce en fonction d'une racine, du pid, du tid et d'un compteur.
Elle est correcte.

EINVAL semble provenir de l'appel write() sous-jacent à fprintf().
Dans la doc, je lis :

[EINVAL] The pointer associated with d was negative.
[EINVAL] The total length of the I/O is more than can be
expressed by the ssize_t return value.

Je ne vois pas trop comment je pourrais être dans l'un des deux cas.
Peut-être dans le premier, mais je ne vois pas comment je pourrais
influer sur le pointeur asocié au descripteur de fichiers...

Une idée ?





Non, j'en suis désolé.


JKB



Je viens de compiler strace pour voir si j'arrivais à avoir un peu
plus d'information, mais strace ne retourne aucun appel système (!).
Sur aucun programme d'ailleurs, ce qui est étrange. Pourtant la
liste des appels systèmes a bien été générée lors de la compilation
du paquet...




Sous un BSD, j'ai plutôt tendance à utiliser le couple ktrace/kdump qui, détail
non négligeable, est intégré au système.

Peut-être auras tu plus de chance de voir où se situe le problème avec ce
couple ?



Je vais essayer de voir. Là, tout de suite, j'ai mis mon NetBSD
fautif totalement en vrac avec un sysupgrade...

Ce qui est assez bizarre, c'est que le même programme (même binaire)
fonctionne parfaitement avec un 5.1.2 et pas avec un 5.1 (?)

Merci du tuyau en tout cas.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Bruno Ducrot
Le #24875312
On 16-10-2012, JKB wrote:
Sous un BSD, j'ai plutôt tendance à utiliser le couple ktrace/kdump qui, détail
non négligeable, est intégré au système.

Peut-être auras tu plus de chance de voir où se situe le problème avec ce
couple ?



Je vais essayer de voir. Là, tout de suite, j'ai mis mon NetBSD
fautif totalement en vrac avec un sysupgrade...

Ce qui est assez bizarre, c'est que le même programme (même binaire)
fonctionne parfaitement avec un 5.1.2 et pas avec un 5.1 (?)




Et bien, la seule idée qui me vienne à l'esprit est qu'il y a eu un
problème *avant* fprintf(). Probablement une corruption des métadonnées
utilisé par malloc(), ce qui impliquerait que le véritable bug est avant
le fprintf().

Tu devrais peut-être essayer de faire tourner ton programme avec efence, ou
bien valgrind (mais je ne sais pas si ce dernier a été porté sous NetBSD).

A plsus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
JKB
Le #24875422
Le 16 Oct 2012 13:21:49 GMT,
Bruno Ducrot
On 16-10-2012, JKB wrote:
Sous un BSD, j'ai plutôt tendance à utiliser le couple ktrace/kdump qui, détail
non négligeable, est intégré au système.

Peut-être auras tu plus de chance de voir où se situe le problème avec ce
couple ?



Je vais essayer de voir. Là, tout de suite, j'ai mis mon NetBSD
fautif totalement en vrac avec un sysupgrade...

Ce qui est assez bizarre, c'est que le même programme (même binaire)
fonctionne parfaitement avec un 5.1.2 et pas avec un 5.1 (?)




Et bien, la seule idée qui me vienne à l'esprit est qu'il y a eu un
problème *avant* fprintf(). Probablement une corruption des métadonnées
utilisé par malloc(), ce qui impliquerait que le véritable bug est avant
le fprintf().

Tu devrais peut-être essayer de faire tourner ton programme avec efence, ou
bien valgrind (mais je ne sais pas si ce dernier a été porté sous NetBSD).



J'ai bien essayé avec valgrind (mais sous Linux) sans gros succès...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Tonton Th
Le #24875572
On 10/16/2012 03:02 PM, JKB wrote:

if ((f_source = fopen(nom_fichier_temporaire, "w")) == NULL)









Pour une raison quelconque, genre ACL, ton fichier ne
serait pas dans un mode "append only" ?


--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Bruno Ducrot
Le #24875712
On 16-10-2012, JKB wrote:
Et bien, la seule idée qui me vienne à l'esprit est qu'il y a eu un
problème *avant* fprintf(). Probablement une corruption des métadonnées
utilisé par malloc(), ce qui impliquerait que le véritable bug est avant
le fprintf().

Tu devrais peut-être essayer de faire tourner ton programme avec efence, ou
bien valgrind (mais je ne sais pas si ce dernier a été porté sous NetBSD).



J'ai bien essayé avec valgrind (mais sous Linux) sans gros succès...




Bon, bah, ca doit être autre chose :( Peut-être un changement d'ABI subtil,
mais j'ai quand même un doute, Les deux versions de NetBSD étant trop proche
AMHA.

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
JKB
Le #24875702
Le Tue, 16 Oct 2012 16:54:22 +0200,
Tonton Th
On 10/16/2012 03:02 PM, JKB wrote:

if ((f_source = fopen(nom_fichier_temporaire, "w")) == NULL)









Pour une raison quelconque, genre ACL, ton fichier ne
serait pas dans un mode "append only" ?



Le fichier n'existe pas. Je le crée.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Patrick Lamaizière
Le #24876862
JKB :

Une idée ?



Peut-être que NetBSD crée un thread pour son printf ?
(je sors)

Plus sérieusement j'ai une confiance limitée dans virtualbox, par
exemple avec OpenBSD y'a plein de segfaults plus ou moins aléatoires
quand les options de virtualisations CPU ne sont pas dispo.
JKB
Le #24876912
Le Wed, 17 Oct 2012 07:53:24 +0200,
Patrick Lamaizière
JKB :

Une idée ?



Peut-être que NetBSD crée un thread pour son printf ?
(je sors)



C'est malin, ça ;-)

Plus sérieusement j'ai une confiance limitée dans virtualbox, par
exemple avec OpenBSD y'a plein de segfaults plus ou moins aléatoires
quand les options de virtualisations CPU ne sont pas dispo.



Tiens, je vais voir cela. Mais les options de virtualisation sont
bien activés sur la machine en question. Il est vrai que j'utilise
la libsigsegv qui fait peut-être des choses bizarres que n'aime pas
virtualbox. En tout état de cause, un NetBSD virtualisé sur du Xen
roule bien, lui...

Avec un 6.0_RC2 tout frais, même motif, même punition. Je viens de
terminer la compilation d'un gcc-4.7 histoire d'éliminer un doute
parce que j'ai déjà constaté des problèmes tordus avec les gcc
4.6/4.7.

Très honnêtement, je ne suis pas sûr que le problème vienne de
NetBSD lui-même et je crois qu'il ne me reste plus que la bissection
du code :-(

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme