[FreeBSD 8] sig_info.pid

Le
JKB
Bonjour à tous,

Petite question du samedi matin ;-) J'ai l'impression que j'ai levé
un lièvre qui me semble assez gros dans FreeBSD 8-STABLE i386 et
concernant sig_info->pid qui vaut toujours 0 chez moi alors qu'il
devrait indiquer le PID du processus ayant envoyé le signal à
traiter. Il était correctement renseigné dans 7.x. Le problème me semble
gros et j'aimerais savoir avant d'aller mettre les pattes dans la libc si
je suis le seul à observer ce genre de problème où si ça vient de
mon installation. En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !

Pour information, le bug report est le
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick Lamaizière
Le #20837601
JKB :

En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !



Je ne crois pas que le champ severity et priority signifient quoi que ce
soit dans le traitement / prise en compte des PR.
JKB
Le #20838591
Le 26-12-2009, ? propos de
Re: [FreeBSD 8] sig_info.pid,
Patrick Lamaizière ?crivait dans fr.comp.os.bsd :
JKB :

En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !



Je ne crois pas que le champ severity et priority signifient quoi que ce
soit dans le traitement / prise en compte des PR.



Dans ce cas, bonne nouvelle. Je m'étonne tout de même qu'un tel
problème ait pu passer inaperçu. Je ne suis tout de même pas le seul
à utiliser cette information ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Patrick Lamaizière
Le #20839071
JKB :

En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !



Je ne crois pas que le champ severity et priority signifient quoi que ce
soit dans le traitement / prise en compte des PR.



Dans ce cas, bonne nouvelle. Je m'étonne tout de même qu'un tel
problème ait pu passer inaperçu. Je ne suis tout de même pas le seul
à utiliser cette information ?



Aucune idée, j'ai pas vraiment compris ton PR j'avoue.

Honnêtement j'ai parfois l'impression que la base de PR est pipée vers
/dev/null. Faut pas hésiter à causer du problème sur les mailing listes
freebsd, ça touche plus de monde ama.
JKB
Le #20839561
Le 27-12-2009, ? propos de
Re: [FreeBSD 8] sig_info.pid,
Patrick Lamaizière ?crivait dans fr.comp.os.bsd :
JKB :

En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !



Je ne crois pas que le champ severity et priority signifient quoi que ce
soit dans le traitement / prise en compte des PR.



Dans ce cas, bonne nouvelle. Je m'étonne tout de même qu'un tel
problème ait pu passer inaperçu. Je ne suis tout de même pas le seul
à utiliser cette information ?



Aucune idée, j'ai pas vraiment compris ton PR j'avoue.



C'est pourtant simple. Lors de l'appel à un gestionnaire de signal
construit avec SIG_INFO, le champ sig_info->pid _doit_ contenir le
pid du processus ayant envoyé le signal. Dans le cas qui nous
intéresse, cette valeur vaut 0 ! C'est gênant lorsque tu utilises
cette valeur pour gérer l'envoi d'un signal à un groupe de threads
hiérarchisés.

Honnêtement j'ai parfois l'impression que la base de PR est pipée vers
/dev/null. Faut pas hésiter à causer du problème sur les mailing listes
freebsd, ça touche plus de monde ama.



Ouaips, je vais faire ça si ça ne bouge pas dans les quelques jours
qui viennent. J'avoie avoir d'autres choses à faire dans la semaine
que me palucher une bissection de la libc entre 7.2 et 8 !...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Eric Masson
Le #20841921
JKB
'Lut,

Ouaips, je vais faire ça si ça ne bouge pas dans les quelques jours
qui viennent.



Cause en sur -hackers ou -stable.

J'avoie avoir d'autres choses à faire dans la semaine
que me palucher une bissection de la libc entre 7.2 et 8 !...



J'ai jeté un oeil rapide sur le svn, et il ne semble pas y avoir eu de
modifications de code de la libc dans ce domaine depuis 2 ans. Ça
ressemble donc plus à un bug noyau et au vu des développements récents,
ce ne serait pas des plus étonnant.

--
J > Y sont pas normaux chez Teaser. Ils refusent les abonnements.
JRV> Mais si. Nous avons tous 5 bras, 2 tetes et 4 oreilles :-)
Manque juste les yeux et quelque autre outil fort utile.
-+- Wolf in GNU : À la queue comme tout le monde -+-
Bruno Ducrot
Le #20977831
On 2009-12-26, JKB wrote:
Bonjour à tous,

Petite question du samedi matin ;-) J'ai l'impression que j'ai levé
un lièvre qui me semble assez gros dans FreeBSD 8-STABLE i386 et
concernant sig_info->pid qui vaut toujours 0 chez moi alors qu'il
devrait indiquer le PID du processus ayant envoyé le signal à
traiter. Il était correctement renseigné dans 7.x. Le problème me semble
gros et j'aimerais savoir avant d'aller mettre les pattes dans la libc si
je suis le seul à observer ce genre de problème où si ça vient de
mon installation. En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !

Pour information, le bug report est le
si vous avez plus d'information...




J'ai :

~/c> cat t.c
#include #include #include #include

void
handler(int signal, siginfo_t *siginfo, void *context)
{
printf("%d %dn", siginfo->si_pid, getpid());
exit(0);
}

int
main(void)
{
struct sigaction sa;
struct sigaction osa;

sa.sa_sigaction = handler;
sa.sa_flags = SA_NODEFER | SA_ONSTACK | SA_SIGINFO;

sigaction(SIGABRT, &sa, &osa);
abort();
return 0;
}
~/c> gcc -Wall -Wextra t.c
t.c:8: warning: unused parameter 'signal'
t.c:8: warning: unused parameter 'context'
~/c> ./a.out
0 70679
~/c> uname -a
FreeBSD poupee.localdomain 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Sep 24
13:37:03 CEST 2009
:/usr/obj/usr/src/sys/GENERIC i386

Donc, a moins que je me sois vautre dans l'ecriture de mon programme de
test, j'ai l'impression que ce bug soit plus ancien.

A plus,

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
JKB
Le #20978201
Le 15-01-2010, ? propos de
Re: [FreeBSD 8] sig_info.pid,
Bruno Ducrot ?crivait dans fr.comp.os.bsd :
On 2009-12-26, JKB wrote:
Bonjour à tous,

Petite question du samedi matin ;-) J'ai l'impression que j'ai levé
un lièvre qui me semble assez gros dans FreeBSD 8-STABLE i386 et
concernant sig_info->pid qui vaut toujours 0 chez moi alors qu'il
devrait indiquer le PID du processus ayant envoyé le signal à
traiter. Il était correctement renseigné dans 7.x. Le problème me semble
gros et j'aimerais savoir avant d'aller mettre les pattes dans la libc si
je suis le seul à observer ce genre de problème où si ça vient de
mon installation. En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !

Pour information, le bug report est le
si vous avez plus d'information...




J'ai :

~/c> cat t.c
#include #include #include #include

void
handler(int signal, siginfo_t *siginfo, void *context)
{
printf("%d %dn", siginfo->si_pid, getpid());
exit(0);
}

int
main(void)
{
struct sigaction sa;
struct sigaction osa;

sa.sa_sigaction = handler;
sa.sa_flags = SA_NODEFER | SA_ONSTACK | SA_SIGINFO;

sigaction(SIGABRT, &sa, &osa);
abort();
return 0;
}
~/c> gcc -Wall -Wextra t.c
t.c:8: warning: unused parameter 'signal'
t.c:8: warning: unused parameter 'context'
~/c> ./a.out
0 70679
~/c> uname -a
FreeBSD poupee.localdomain 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Sep 24
13:37:03 CEST 2009
:/usr/obj/usr/src/sys/GENERIC i386

Donc, a moins que je me sois vautre dans l'ecriture de mon programme de
test, j'ai l'impression que ce bug soit plus ancien.



Comme ça, ça a l'air bon. J'avais installé la machine avec une
7.0-RELEASE, passée en 7.2-RELEASE et ça fonctionnait. C'est le
passage à la 8-STABLE qui a fait merdoyer mon programme. Maintenant,
je n'ai pas cherché plus que ça dans les anciennes versions.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Bruno Ducrot
Le #20979231
On 2010-01-15, JKB wrote:
~/c> cat t.c
#include #include #include #include

void
handler(int signal, siginfo_t *siginfo, void *context)
{
printf("%d %dn", siginfo->si_pid, getpid());
exit(0);
}

int
main(void)
{
struct sigaction sa;
struct sigaction osa;

sa.sa_sigaction = handler;
sa.sa_flags = SA_NODEFER | SA_ONSTACK | SA_SIGINFO;

sigaction(SIGABRT, &sa, &osa);
abort();
return 0;
}
~/c> gcc -Wall -Wextra t.c
t.c:8: warning: unused parameter 'signal'
t.c:8: warning: unused parameter 'context'
~/c> ./a.out
0 70679
~/c> uname -a
FreeBSD poupee.localdomain 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Sep 24
13:37:03 CEST 2009
:/usr/obj/usr/src/sys/GENERIC i386

Donc, a moins que je me sois vautre dans l'ecriture de mon programme de
test, j'ai l'impression que ce bug soit plus ancien.



Comme ça, ça a l'air bon. J'avais installé la machine avec une
7.0-RELEASE, passée en 7.2-RELEASE et ça fonctionnait. C'est le
passage à la 8-STABLE qui a fait merdoyer mon programme. Maintenant,
je n'ai pas cherché plus que ça dans les anciennes versions.



Aie !! Si l'on remplace le sig handler par :

void
handler(int signal, siginfo_t *siginfo, void *context)
{
int i;
char *p = (char *)siginfo;

for (i = 0; i < sizeof *siginfo; ++i) {
if (i%8 == 0)
printf("n");
printf("%.2hhx ", p[i]);
}
printf("n");

_exit(1);
}

alors l'on obtient :

~/c> ./a.out

06 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Seul le champ si_signo de la structure est correct :(

A plus,

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot
Le #21074841
On 2010-01-15, Bruno Ducrot wrote:
On 2009-12-26, JKB wrote:
Bonjour à tous,

Petite question du samedi matin ;-) J'ai l'impression que j'ai levé
un lièvre qui me semble assez gros dans FreeBSD 8-STABLE i386 et
concernant sig_info->pid qui vaut toujours 0 chez moi alors qu'il
devrait indiquer le PID du processus ayant envoyé le signal à
traiter. Il était correctement renseigné dans 7.x. Le problème me semble
gros et j'aimerais savoir avant d'aller mettre les pattes dans la libc si
je suis le seul à observer ce genre de problème où si ça vient de
mon installation. En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !

Pour information, le bug report est le
si vous avez plus d'information...





Pour info, c'est corrige (en fait, c'etait deja dans CURRENT, mais pas
dans STABLE quand tu as emis le PR).

~/c> cat test_sa_sigaction.c
#include #include #include #include

void
handler(int signal, siginfo_t *siginfo, void *context)
{
int i;
char *p = (char *)siginfo;

printf("si_pid: %d (%d)n", siginfo->si_pid, getpid());
printf("si_uid: %dn", siginfo->si_uid);

_exit(1);
}

int
main(void)
{
struct sigaction sa;

sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO;
sigemptyset(&sa.sa_mask);

sigaction(SIGABRT, &sa, NULL);
abort();
return 0;
}
~/c> gcc test_sa_sigaction.c
~/c> ./a.out
si_pid: 1812 (1812)
si_uid: 1000
~/c> uname -a
FreeBSD poupee.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Jan 28 18:02:37 CET 2010 :/usr/obj/usr/src/sys/GENERIC i386

A plus,

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
JKB
Le #21074831
Le 28-01-2010, ? propos de
Re: [FreeBSD 8] sig_info.pid,
Bruno Ducrot ?crivait dans fr.comp.os.bsd :
On 2010-01-15, Bruno Ducrot wrote:
On 2009-12-26, JKB wrote:
Bonjour à tous,

Petite question du samedi matin ;-) J'ai l'impression que j'ai levé
un lièvre qui me semble assez gros dans FreeBSD 8-STABLE i386 et
concernant sig_info->pid qui vaut toujours 0 chez moi alors qu'il
devrait indiquer le PID du processus ayant envoyé le signal à
traiter. Il était correctement renseigné dans 7.x. Le problème me semble
gros et j'aimerais savoir avant d'aller mettre les pattes dans la libc si
je suis le seul à observer ce genre de problème où si ça vient de
mon installation. En fait, ce qui m'inquiète, c'est que l'équipe de
FreeBSD a mis ce bug en priorité basse alors qu'il doit poser de
sérieux problèmes !

Pour information, le bug report est le
si vous avez plus d'information...





Pour info, c'est corrige (en fait, c'etait deja dans CURRENT, mais pas
dans STABLE quand tu as emis le PR).

~/c> cat test_sa_sigaction.c
#include #include #include #include

void
handler(int signal, siginfo_t *siginfo, void *context)
{
int i;
char *p = (char *)siginfo;

printf("si_pid: %d (%d)n", siginfo->si_pid, getpid());
printf("si_uid: %dn", siginfo->si_uid);

_exit(1);
}

int
main(void)
{
struct sigaction sa;

sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO;
sigemptyset(&sa.sa_mask);

sigaction(SIGABRT, &sa, NULL);
abort();
return 0;
}
~/c> gcc test_sa_sigaction.c
~/c> ./a.out
si_pid: 1812 (1812)
si_uid: 1000
~/c> uname -a
FreeBSD poupee.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Jan 28 18:02:37 CET 2010 :/usr/obj/usr/src/sys/GENERIC i386



Merci.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Publicité
Poster une réponse
Anonyme