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 !
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 !
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 !
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 :
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 :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.
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 ?
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 ?
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 :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 :
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 :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.
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 !...
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 !...
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 !...
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...
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...
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...
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information...
J'ai :
~/c> cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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.
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information...
J'ai :
bruno@poupee ~/c> cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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;
}
bruno@poupee ~/c> gcc -Wall -Wextra t.c
t.c:8: warning: unused parameter 'signal'
t.c:8: warning: unused parameter 'context'
bruno@poupee ~/c> ./a.out
0 70679
bruno@poupee ~/c> uname -a
FreeBSD poupee.localdomain 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Sep 24
13:37:03 CEST 2009
root@poupee.localdomain:/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.
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information...
J'ai :
~/c> cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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.
~/c> cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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.
bruno@poupee ~/c> cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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;
}
bruno@poupee ~/c> gcc -Wall -Wextra t.c
t.c:8: warning: unused parameter 'signal'
t.c:8: warning: unused parameter 'context'
bruno@poupee ~/c> ./a.out
0 70679
bruno@poupee ~/c> uname -a
FreeBSD poupee.localdomain 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Sep 24
13:37:03 CEST 2009
root@poupee.localdomain:/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.
~/c> cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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.
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information...
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information...
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
si vous avez plus d'information...
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
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 <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
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).
bruno@poupee ~/c> cat test_sa_sigaction.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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;
}
bruno@poupee ~/c> gcc test_sa_sigaction.c
bruno@poupee ~/c> ./a.out
si_pid: 1812 (1812)
si_uid: 1000
bruno@poupee ~/c> uname -a
FreeBSD poupee.localdomain 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Jan 28 18:02:37 CET 2010 root@poupee.localdomain:/usr/obj/usr/src/sys/GENERIC i386
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
<http://www.freebsd.org/cgi/query-pr.cgi?pr1956&cat=>
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 <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
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