Je viens de tomber sur un OS avec OpenBSD et je ne comprends pas
bien ce qui se passe.
Considérons le code suivant :
if ((s_etat_processus.pile_signal.ss_sp =
malloc(s_etat_processus.pile_signal.ss_size =
SIGSTKSZ)) == NULL)
{
// Gestion de l'erreur sans aucun intérêt ici
exit(EXIT_FAILURE);
}
s_etat_processus.pile_signal.ss_flags = 0;
if (sigaltstack(&s_etat_processus.pile_signal, NULL) != 0)
{
perror("");
exit(EXIT_FAILURE);
}
...
J'ai testé sous :
- Solaris 9 sparc : OK
- Solaris 10 sparc, i386 : OK
- Linux 2.6 (debian) i386, amd64, sparc64 : OK
- NetBSD 4.0 sparc : OK
- OpenBSD 4.3 i386 : KO !
Sous OpenBSD 4.3, perror() m'affiche un superbe "Invalid argument".
Je viens de lire, relire, rerelire, rererelire... la page de man de
sigaltstack (sous OpenBSD), je ne vois pas ce qui n'est pas bon et
en quoi j'ai écrit une conn^Wbêtise.
Une idée ?
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.
Le 19-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Miod Vallat écrivait dans fr.comp.os.bsd :
J'ai dû écrire une absurdité, mais je ne vois toujours pas laquelle.
Ça a l'air correct pourtant. Que donne un kdump du ktrace, histoire de connaître les valeurs exactes passées à l'appel système ?
Là, ça dépasse mes compétences...
gauss:[~/rpl/build/src] > ktrace ./rpl -is +++RPL/2 (R) version 4.0.0.prerelease.7 (Thursday 06/19/08, 18:41:03 CEST) +++Copyright (C) 1989 à 2007, 2008 BERTRAND Joël +++Système : Initialisation de la pile spécifique de signal impossible gauss:[~/rpl/build/src] >
Et le kdump me donne (en fin la fin du kdump...) :
12507 rpl RET mprotect 0 12507 rpl CALL sigprocmask(0x3,0) 12507 rpl RET sigprocmask -65793/0xfffefeff 12507 rpl CALL write(0x2,0x3c011920,0x33) 12507 rpl GIO fd 2 wrote 51 bytes "+++Copyright (C) 1989 M-C240 2007, 2008 BERTRAND JoM-CM-+l " 12507 rpl RET write 51/0x33 12507 rpl CALL sigprocmask(0x1,0xffffffff) 12507 rpl RET sigprocmask 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x3) 12507 rpl RET mprotect 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x1) 12507 rpl RET mprotect 0 12507 rpl CALL sigprocmask(0x3,0) 12507 rpl RET sigprocmask -65793/0xfffefeff 12507 rpl CALL mmap(0,0xa000,0x3,0x1002,0xffffffff,0,0,0) 12507 rpl RET mmap -1964806144/0x8ae37000 12507 rpl CALL sigprocmask(0x1,0xffffffff) 12507 rpl RET sigprocmask 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x3) 12507 rpl RET mprotect 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x1) 12507 rpl RET mprotect 0 12507 rpl CALL sigprocmask(0x3,0) 12507 rpl RET sigprocmask -65793/0xfffefeff 12507 rpl CALL write(0x2,0x3c0119d0,0x49) 12507 rpl GIO fd 2 wrote 73 bytes "+++SystM-CM-(me : Initialisation de la pile spM-CM-)cifique de sig nal impossible ...
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.
Le 19-06-2008, à propos de
Re: Portabilité Solaris/Linux/NetBSD/OpenBSD,
Miod Vallat écrivait dans fr.comp.os.bsd :
J'ai dû écrire une absurdité, mais je ne vois toujours pas laquelle.
Ça a l'air correct pourtant. Que donne un kdump du ktrace, histoire de
connaître les valeurs exactes passées à l'appel système ?
Là, ça dépasse mes compétences...
gauss:[~/rpl/build/src] > ktrace ./rpl -is
+++RPL/2 (R) version 4.0.0.prerelease.7 (Thursday 06/19/08, 18:41:03 CEST)
+++Copyright (C) 1989 à 2007, 2008 BERTRAND Joël
+++Système : Initialisation de la pile spécifique de signal impossible
gauss:[~/rpl/build/src] >
Et le kdump me donne (en fin la fin du kdump...) :
12507 rpl RET mprotect 0
12507 rpl CALL sigprocmask(0x3,0)
12507 rpl RET sigprocmask -65793/0xfffefeff
12507 rpl CALL write(0x2,0x3c011920,0x33)
12507 rpl GIO fd 2 wrote 51 bytes
"+++Copyright (C) 1989 M-C240 2007, 2008 BERTRAND JoM-CM-+l "
12507 rpl RET write 51/0x33
12507 rpl CALL sigprocmask(0x1,0xffffffff)
12507 rpl RET sigprocmask 0
12507 rpl CALL mprotect(0x3c03d000,0x1000,0x3)
12507 rpl RET mprotect 0
12507 rpl CALL mprotect(0x3c03d000,0x1000,0x1)
12507 rpl RET mprotect 0
12507 rpl CALL sigprocmask(0x3,0)
12507 rpl RET sigprocmask -65793/0xfffefeff
12507 rpl CALL mmap(0,0xa000,0x3,0x1002,0xffffffff,0,0,0)
12507 rpl RET mmap -1964806144/0x8ae37000
12507 rpl CALL sigprocmask(0x1,0xffffffff)
12507 rpl RET sigprocmask 0
12507 rpl CALL mprotect(0x3c03d000,0x1000,0x3)
12507 rpl RET mprotect 0
12507 rpl CALL mprotect(0x3c03d000,0x1000,0x1)
12507 rpl RET mprotect 0
12507 rpl CALL sigprocmask(0x3,0)
12507 rpl RET sigprocmask -65793/0xfffefeff
12507 rpl CALL write(0x2,0x3c0119d0,0x49)
12507 rpl GIO fd 2 wrote 73 bytes
"+++SystM-CM-(me : Initialisation de la pile spM-CM-)cifique de sig
nal impossible
...
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.
Le 19-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Miod Vallat écrivait dans fr.comp.os.bsd :
J'ai dû écrire une absurdité, mais je ne vois toujours pas laquelle.
Ça a l'air correct pourtant. Que donne un kdump du ktrace, histoire de connaître les valeurs exactes passées à l'appel système ?
Là, ça dépasse mes compétences...
gauss:[~/rpl/build/src] > ktrace ./rpl -is +++RPL/2 (R) version 4.0.0.prerelease.7 (Thursday 06/19/08, 18:41:03 CEST) +++Copyright (C) 1989 à 2007, 2008 BERTRAND Joël +++Système : Initialisation de la pile spécifique de signal impossible gauss:[~/rpl/build/src] >
Et le kdump me donne (en fin la fin du kdump...) :
12507 rpl RET mprotect 0 12507 rpl CALL sigprocmask(0x3,0) 12507 rpl RET sigprocmask -65793/0xfffefeff 12507 rpl CALL write(0x2,0x3c011920,0x33) 12507 rpl GIO fd 2 wrote 51 bytes "+++Copyright (C) 1989 M-C240 2007, 2008 BERTRAND JoM-CM-+l " 12507 rpl RET write 51/0x33 12507 rpl CALL sigprocmask(0x1,0xffffffff) 12507 rpl RET sigprocmask 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x3) 12507 rpl RET mprotect 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x1) 12507 rpl RET mprotect 0 12507 rpl CALL sigprocmask(0x3,0) 12507 rpl RET sigprocmask -65793/0xfffefeff 12507 rpl CALL mmap(0,0xa000,0x3,0x1002,0xffffffff,0,0,0) 12507 rpl RET mmap -1964806144/0x8ae37000 12507 rpl CALL sigprocmask(0x1,0xffffffff) 12507 rpl RET sigprocmask 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x3) 12507 rpl RET mprotect 0 12507 rpl CALL mprotect(0x3c03d000,0x1000,0x1) 12507 rpl RET mprotect 0 12507 rpl CALL sigprocmask(0x3,0) 12507 rpl RET sigprocmask -65793/0xfffefeff 12507 rpl CALL write(0x2,0x3c0119d0,0x49) 12507 rpl GIO fd 2 wrote 73 bytes "+++SystM-CM-(me : Initialisation de la pile spM-CM-)cifique de sig nal impossible ...
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.
Eric Levenez
Juste pour info, dans ton code tu mélanges des "char" et des "unsigned char", quand on compile on a plein de warning pas propres du tout (getenv...). Il y a aussi le getuid que tu testes avec -1, il faut caster avec "(uid_t)" pour que ça compile sans erreur.
Tu postes un code marchant et un bout de code ne marchant pas. Comme le second code ne compile pas et n'est pas complet, on ne peut pas vraiment savoir ce qui se passe (écrasement mémoire...).
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and (more or less) MacOS X. It is not available on OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Juste pour info, dans ton code tu mélanges des "char" et des "unsigned
char", quand on compile on a plein de warning pas propres du tout
(getenv...). Il y a aussi le getuid que tu testes avec -1, il faut caster
avec "(uid_t)" pour que ça compile sans erreur.
Tu postes un code marchant et un bout de code ne marchant pas. Comme le
second code ne compile pas et n'est pas complet, on ne peut pas vraiment
savoir ce qui se passe (écrasement mémoire...).
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on
Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and
(more or less) MacOS X.
It is not available on
OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
Juste pour info, dans ton code tu mélanges des "char" et des "unsigned char", quand on compile on a plein de warning pas propres du tout (getenv...). Il y a aussi le getuid que tu testes avec -1, il faut caster avec "(uid_t)" pour que ça compile sans erreur.
Tu postes un code marchant et un bout de code ne marchant pas. Comme le second code ne compile pas et n'est pas complet, on ne peut pas vraiment savoir ce qui se passe (écrasement mémoire...).
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and (more or less) MacOS X. It is not available on OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
JKB
Le 19-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Eric Levenez écrivait dans fr.comp.os.unix :
Juste pour info, dans ton code tu mélanges des "char" et des "unsigned char", quand on compile on a plein de warning pas propres du tout (getenv...).
J'ai une option de gcc qui considère les char comme unsigned (c'est pour pouvoir traiter les chaînes à la façon du Fortran plus loin dans le code).
Il y a aussi le getuid que tu testes avec -1, il faut caster avec "(uid_t)" pour que ça compile sans erreur.
Tiens, effectivement, c'est à corriger...
Tu postes un code marchant et un bout de code ne marchant pas. Comme le second code ne compile pas et n'est pas complet, on ne peut pas vraiment savoir ce qui se passe (écrasement mémoire...).
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and (more or less) MacOS X. It is not available on OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
J'ai une page man sous OpenBSD et l'appel fonctionne avec un exemple minimal. Qu'il soit buggué jusqu'à la moëlle, c'est possible...
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.
Le 19-06-2008, à propos de
Re: Portabilité Solaris/Linux/NetBSD/OpenBSD,
Eric Levenez écrivait dans fr.comp.os.unix :
Juste pour info, dans ton code tu mélanges des "char" et des "unsigned
char", quand on compile on a plein de warning pas propres du tout
(getenv...).
J'ai une option de gcc qui considère les char comme unsigned (c'est
pour pouvoir traiter les chaînes à la façon du Fortran plus loin
dans le code).
Il y a aussi le getuid que tu testes avec -1, il faut caster
avec "(uid_t)" pour que ça compile sans erreur.
Tiens, effectivement, c'est à corriger...
Tu postes un code marchant et un bout de code ne marchant pas. Comme le
second code ne compile pas et n'est pas complet, on ne peut pas vraiment
savoir ce qui se passe (écrasement mémoire...).
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on
Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and
(more or less) MacOS X.
It is not available on
OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
J'ai une page man sous OpenBSD et l'appel fonctionne avec un exemple
minimal. Qu'il soit buggué jusqu'à la moëlle, c'est possible...
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.
Le 19-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Eric Levenez écrivait dans fr.comp.os.unix :
Juste pour info, dans ton code tu mélanges des "char" et des "unsigned char", quand on compile on a plein de warning pas propres du tout (getenv...).
J'ai une option de gcc qui considère les char comme unsigned (c'est pour pouvoir traiter les chaînes à la façon du Fortran plus loin dans le code).
Il y a aussi le getuid que tu testes avec -1, il faut caster avec "(uid_t)" pour que ça compile sans erreur.
Tiens, effectivement, c'est à corriger...
Tu postes un code marchant et un bout de code ne marchant pas. Comme le second code ne compile pas et n'est pas complet, on ne peut pas vraiment savoir ce qui se passe (écrasement mémoire...).
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and (more or less) MacOS X. It is not available on OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
J'ai une page man sous OpenBSD et l'appel fonctionne avec un exemple minimal. Qu'il soit buggué jusqu'à la moëlle, c'est possible...
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.
Stephane CHAZELAS
2008-06-19, 18:53(+02), Eric Levenez: [...]
J'ai trouvé cela avec Google :
" - sigaltstack is present and works on Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and (more or less) MacOS X. It is not available on OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
" - sigaltstack is present and works on
Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and
(more or less) MacOS X.
It is not available on
OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
" - sigaltstack is present and works on Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and (more or less) MacOS X. It is not available on OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS. "
J'ai l'impression que vous n'avez pas compilé avec le même compilateur que le programme qui ne fonctionne pas. Est-ce que ca passe toujours avec le GCC que vous aviez compilé ?
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
J'ai l'impression que vous n'avez pas compilé avec le même compilateur
que le programme qui ne fonctionne pas. Est-ce que ca passe toujours
avec le GCC que vous aviez compilé ?
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
J'ai l'impression que vous n'avez pas compilé avec le même compilateur que le programme qui ne fonctionne pas. Est-ce que ca passe toujours avec le GCC que vous aviez compilé ?
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
JKB
Le 20-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Bruno Ducrot écrivait dans fr.comp.os.unix :
J'ai l'impression que vous n'avez pas compilé avec le même compilateur que le programme qui ne fonctionne pas. Est-ce que ca passe toujours avec le GCC que vous aviez compilé ?
Si, c'est le même compilo. Il est dans le path de l'utilisateur _avant_ le gcc du système (pour que gfortran ne gueule pas lorsqu'il se trouve avec gcc-3.3).
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.
Le 20-06-2008, à propos de
Re: Portabilité Solaris/Linux/NetBSD/OpenBSD,
Bruno Ducrot écrivait dans fr.comp.os.unix :
J'ai l'impression que vous n'avez pas compilé avec le même compilateur
que le programme qui ne fonctionne pas. Est-ce que ca passe toujours
avec le GCC que vous aviez compilé ?
Si, c'est le même compilo. Il est dans le path de l'utilisateur
_avant_ le gcc du système (pour que gfortran ne gueule pas lorsqu'il
se trouve avec gcc-3.3).
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.
J'ai l'impression que vous n'avez pas compilé avec le même compilateur que le programme qui ne fonctionne pas. Est-ce que ca passe toujours avec le GCC que vous aviez compilé ?
Si, c'est le même compilo. Il est dans le path de l'utilisateur _avant_ le gcc du système (pour que gfortran ne gueule pas lorsqu'il se trouve avec gcc-3.3).
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
On 2008-06-20, JKB wrote:
Le 20-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Bruno Ducrot écrivait dans fr.comp.os.unix :
J'ai l'impression que vous n'avez pas compilé avec le même compilateur que le programme qui ne fonctionne pas. Est-ce que ca passe toujours avec le GCC que vous aviez compilé ?
Si, c'est le même compilo. Il est dans le path de l'utilisateur _avant_ le gcc du système (pour que gfortran ne gueule pas lorsqu'il se trouve avec gcc-3.3).
OK. Le pire, c'est que vous aviez donné la sortie de gcc -v. Je ferai gaffe la prochaine fois.
Par contre, avez-vous essayer de remplacer l'appel a sigaltstack par un syscall() ? Quelque chose comme :
if (syscall(288, &s_processus.pile_system, NULL) != 0)
au lieu de
if (sysaltstack(&s_processus.pile_system, NULL) != 0)
Le 288 provient de http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/syscall.h?rev=1.101&content-type=text/plain
On a en effet : ... #define SYS_osigaltstack 53 ... #define SYS_sigaltstack 288
A priori, il existe deux appels systemes sous OpenBSD, celui suffixé par 'o' est probablement présente pour des raisons de compatibilité.
Bon courage,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2008-06-20, JKB wrote:
Le 20-06-2008, à propos de
Re: Portabilité Solaris/Linux/NetBSD/OpenBSD,
Bruno Ducrot écrivait dans fr.comp.os.unix :
J'ai l'impression que vous n'avez pas compilé avec le même compilateur
que le programme qui ne fonctionne pas. Est-ce que ca passe toujours
avec le GCC que vous aviez compilé ?
Si, c'est le même compilo. Il est dans le path de l'utilisateur
_avant_ le gcc du système (pour que gfortran ne gueule pas lorsqu'il
se trouve avec gcc-3.3).
OK. Le pire, c'est que vous aviez donné la sortie de gcc -v. Je ferai
gaffe la prochaine fois.
Par contre, avez-vous essayer de remplacer l'appel a sigaltstack par un
syscall() ? Quelque chose comme :
if (syscall(288, &s_processus.pile_system, NULL) != 0)
au lieu de
if (sysaltstack(&s_processus.pile_system, NULL) != 0)
Le 288 provient de
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/syscall.h?rev=1.101&content-type=text/plain
On a en effet :
...
#define SYS_osigaltstack 53
...
#define SYS_sigaltstack 288
A priori, il existe deux appels systemes sous OpenBSD, celui suffixé par
'o' est probablement présente pour des raisons de compatibilité.
Bon courage,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
J'ai l'impression que vous n'avez pas compilé avec le même compilateur que le programme qui ne fonctionne pas. Est-ce que ca passe toujours avec le GCC que vous aviez compilé ?
Si, c'est le même compilo. Il est dans le path de l'utilisateur _avant_ le gcc du système (pour que gfortran ne gueule pas lorsqu'il se trouve avec gcc-3.3).
OK. Le pire, c'est que vous aviez donné la sortie de gcc -v. Je ferai gaffe la prochaine fois.
Par contre, avez-vous essayer de remplacer l'appel a sigaltstack par un syscall() ? Quelque chose comme :
if (syscall(288, &s_processus.pile_system, NULL) != 0)
au lieu de
if (sysaltstack(&s_processus.pile_system, NULL) != 0)
Le 288 provient de http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/syscall.h?rev=1.101&content-type=text/plain
On a en effet : ... #define SYS_osigaltstack 53 ... #define SYS_sigaltstack 288
A priori, il existe deux appels systemes sous OpenBSD, celui suffixé par 'o' est probablement présente pour des raisons de compatibilité.
Bon courage,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Gabriel Linder
On Thu, 19 Jun 2008 18:37:10 +0000, Miod Vallat wrote:
Super, aucun appel à sigaltstack... Ça sent le gcc faisandé, ça.
Je viens de voir qu'un bug a été identifié dans GCC 4.3.1 (utilisé par JKB), peut être que son problème est lié (un problème de registre apparemment). cf http://kerneltrap.org/Linux/Compiler_Oops
On Thu, 19 Jun 2008 18:37:10 +0000, Miod Vallat wrote:
Super, aucun appel à sigaltstack... Ça sent le gcc faisandé, ça.
Je viens de voir qu'un bug a été identifié dans GCC 4.3.1 (utilisé par
JKB), peut être que son problème est lié (un problème de registre
apparemment). cf http://kerneltrap.org/Linux/Compiler_Oops
On Thu, 19 Jun 2008 18:37:10 +0000, Miod Vallat wrote:
Super, aucun appel à sigaltstack... Ça sent le gcc faisandé, ça.
Je viens de voir qu'un bug a été identifié dans GCC 4.3.1 (utilisé par JKB), peut être que son problème est lié (un problème de registre apparemment). cf http://kerneltrap.org/Linux/Compiler_Oops
JKB
Le 20-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Gabriel Linder écrivait dans fr.comp.os.bsd :
On Thu, 19 Jun 2008 18:37:10 +0000, Miod Vallat wrote:
Super, aucun appel à sigaltstack... Ça sent le gcc faisandé, ça.
Je viens de voir qu'un bug a été identifié dans GCC 4.3.1 (utilisé par JKB), peut être que son problème est lié (un problème de registre apparemment). cf http://kerneltrap.org/Linux/Compiler_Oops
Recompilé avec gcc-3.3.5 (origine OpenBSD), le problème reste le même...
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.
Le 20-06-2008, à propos de
Re: Portabilité Solaris/Linux/NetBSD/OpenBSD,
Gabriel Linder écrivait dans fr.comp.os.bsd :
On Thu, 19 Jun 2008 18:37:10 +0000, Miod Vallat wrote:
Super, aucun appel à sigaltstack... Ça sent le gcc faisandé, ça.
Je viens de voir qu'un bug a été identifié dans GCC 4.3.1 (utilisé par
JKB), peut être que son problème est lié (un problème de registre
apparemment). cf http://kerneltrap.org/Linux/Compiler_Oops
Recompilé avec gcc-3.3.5 (origine OpenBSD), le problème reste le
même...
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.
Le 20-06-2008, à propos de Re: Portabilité Solaris/Linux/NetBSD/OpenBSD, Gabriel Linder écrivait dans fr.comp.os.bsd :
On Thu, 19 Jun 2008 18:37:10 +0000, Miod Vallat wrote:
Super, aucun appel à sigaltstack... Ça sent le gcc faisandé, ça.
Je viens de voir qu'un bug a été identifié dans GCC 4.3.1 (utilisé par JKB), peut être que son problème est lié (un problème de registre apparemment). cf http://kerneltrap.org/Linux/Compiler_Oops
Recompilé avec gcc-3.3.5 (origine OpenBSD), le problème reste le même...
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.