[NetBSD] Comportement étrange de fprintf()

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

Le Tue, 16 Oct 2012 08:39:36 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :

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...

Bonjour,

On 16-10-2012, JKB wrote:

Le Tue, 16 Oct 2012 08:39:36 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :

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 ?

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 (?)

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).

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

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...

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" ?

Une idée ?

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.