J'ai un petit problème de plantage dans une application Carbon sous Mac OS
X.
L'appli est écrite en C avec CodeWarrior.
Le plantage se fait sur le return d'une fonction (?) qui est elle-même
appelée d'une autre fonction, qui est appelée d'une autre fonction... ...
qui est appelée du main de l'appli.
Le debugger dit qu'il y a une 'access default exception' et affiche dans la
pile d'exécution deux fonctions de type PPC, alors qu'en début d'exécution
de cette fonction il affichait une pile d'exécution correcte avec --start,
main, ...
Je pratique la programmation C sur Mac depuis un temps certain et est déjà
porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur,
mais j'avoue que je suis un peu surpris sur ce coup...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Stadelmann
In article <bidcp9$b8m$, "Philippe Legroux" wrote:
Je pratique la programmation C sur Mac depuis un temps certain et est déjà porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur, mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça pouvait arriver très facilement avec un mauvais indice dans un tableau par exemple, vu que les adresses de retour étaient stockées dans la pile avec les variables et les paramètres. Je ne sais pas si c'est toujours le cas aujourd'hui.
Patrick -- Patrick Stadelmann
In article <bidcp9$b8m$1@news-reader1.wanadoo.fr>,
"Philippe Legroux" <philippe_legroux@hotmail.com> wrote:
Je pratique la programmation C sur Mac depuis un temps certain et est déjà
porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur,
mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça
pouvait arriver très facilement avec un mauvais indice dans un tableau
par exemple, vu que les adresses de retour étaient stockées dans la pile
avec les variables et les paramètres. Je ne sais pas si c'est toujours
le cas aujourd'hui.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <bidcp9$b8m$, "Philippe Legroux" wrote:
Je pratique la programmation C sur Mac depuis un temps certain et est déjà porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur, mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça pouvait arriver très facilement avec un mauvais indice dans un tableau par exemple, vu que les adresses de retour étaient stockées dans la pile avec les variables et les paramètres. Je ne sais pas si c'est toujours le cas aujourd'hui.
Patrick -- Patrick Stadelmann
Schmurtz
Je pratique la programmation C sur Mac depuis un temps certain et est déjà porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur, mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça pouvait arriver très facilement avec un mauvais indice dans un tableau par exemple, vu que les adresses de retour étaient stockées dans la pile avec les variables et les paramètres. Je ne sais pas si c'est toujours le cas aujourd'hui.
C'est toujours le cas, où veux-tu qu'on les enregistre sinon ?
-- Schmurtz
Je pratique la programmation C sur Mac depuis un temps certain et est déjà
porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur,
mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça
pouvait arriver très facilement avec un mauvais indice dans un tableau
par exemple, vu que les adresses de retour étaient stockées dans la pile
avec les variables et les paramètres. Je ne sais pas si c'est toujours
le cas aujourd'hui.
C'est toujours le cas, où veux-tu qu'on les enregistre sinon ?
Je pratique la programmation C sur Mac depuis un temps certain et est déjà porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur, mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça pouvait arriver très facilement avec un mauvais indice dans un tableau par exemple, vu que les adresses de retour étaient stockées dans la pile avec les variables et les paramètres. Je ne sais pas si c'est toujours le cas aujourd'hui.
C'est toujours le cas, où veux-tu qu'on les enregistre sinon ?
-- Schmurtz
Éric Lévénez
Le 25/08/03 18:56, dans , « Schmurtz » a écrit :
Je pratique la programmation C sur Mac depuis un temps certain et est déjà porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur, mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça pouvait arriver très facilement avec un mauvais indice dans un tableau par exemple, vu que les adresses de retour étaient stockées dans la pile avec les variables et les paramètres. Je ne sais pas si c'est toujours le cas aujourd'hui.
C'est toujours le cas, où veux-tu qu'on les enregistre sinon ?
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour le PPC.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 25/08/03 18:56, dans
<moi-DF949A.18561525082003@polynews.polytechnique.fr>, « Schmurtz »
<moi@ici.com> a écrit :
Je pratique la programmation C sur Mac depuis un temps certain et est déjà
porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur,
mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça
pouvait arriver très facilement avec un mauvais indice dans un tableau
par exemple, vu que les adresses de retour étaient stockées dans la pile
avec les variables et les paramètres. Je ne sais pas si c'est toujours
le cas aujourd'hui.
C'est toujours le cas, où veux-tu qu'on les enregistre sinon ?
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour
le PPC.
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
Je pratique la programmation C sur Mac depuis un temps certain et est déjà porté plusieurs applications de Mac OS 9 vers Mac OS X sans problème majeur, mais j'avoue que je suis un peu surpris sur ce coup...
Une des fonctions doit corrompre la pile. A l'époque du 680x0, ça pouvait arriver très facilement avec un mauvais indice dans un tableau par exemple, vu que les adresses de retour étaient stockées dans la pile avec les variables et les paramètres. Je ne sais pas si c'est toujours le cas aujourd'hui.
C'est toujours le cas, où veux-tu qu'on les enregistre sinon ?
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour le PPC.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <BB700FE3.51B75%, Éric Lévénez wrote:
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour le PPC.
On pourrait aussi imaginer une pile séparée pour les adresses de retour.
Patrick -- Patrick Stadelmann
In article <BB700FE3.51B75%eric@levenez.com>,
Éric Lévénez <eric@levenez.com> wrote:
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour
le PPC.
On pourrait aussi imaginer une pile séparée pour les adresses de retour.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour le PPC.
Ça doit limiter le nombre de récursion car les registres sont limités.
On pourrait aussi imaginer une pile séparée pour les adresses de retour.
Oui
-- Schmurtz
Patrick Stadelmann
In article , Schmurtz wrote:
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour le PPC.
Ça doit limiter le nombre de récursion car les registres sont limités.
Dans ce cas, ça rebascule sur la pile.
On pourrait aussi imaginer une pile séparée pour les adresses de retour.
Oui
Mais apparament ce n'est pas le cas dans Mac OS X. L'adresse de retour est stockée dans un registre, et copiée dans la pile si l'on appelle d'autres routines avant le retour.
Patrick -- Patrick Stadelmann
In article <moi-A3FB35.20550125082003@polynews.polytechnique.fr>,
Schmurtz <moi@ici.com> wrote:
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas
pour
le PPC.
Ça doit limiter le nombre de récursion car les registres sont limités.
Dans ce cas, ça rebascule sur la pile.
On pourrait aussi imaginer une pile séparée pour les adresses de retour.
Oui
Mais apparament ce n'est pas le cas dans Mac OS X. L'adresse de retour
est stockée dans un registre, et copiée dans la pile si l'on appelle
d'autres routines avant le retour.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Dans des registres du CPU, certains CPU RISC font cela, je ne sais pas pour le PPC.
Ça doit limiter le nombre de récursion car les registres sont limités.
Dans ce cas, ça rebascule sur la pile.
On pourrait aussi imaginer une pile séparée pour les adresses de retour.
Oui
Mais apparament ce n'est pas le cas dans Mac OS X. L'adresse de retour est stockée dans un registre, et copiée dans la pile si l'on appelle d'autres routines avant le retour.
Patrick -- Patrick Stadelmann
Schmurtz
Cela ne dépend pas de MacOS X, c'est juste la méthode couramment utilisée. Rien n'empèche de l'enregistrer où on veut.
Et tu expliques comment aux routines (librairies, etc...) que tu appelles que tu as mis l'adresse de retour ailleurs ?
Pas besion car l'enregistrement de l'adresse de retour n'est utilisé qu'à l'intérieur de la routine :
- entrée dans la routine - sauvegarde où tu veux de l'adresse de retour (stoquée dans le registre LR lors de l'appel) - plein de trucs (dont des appels de fonctions) - récupération de l'adresse de retour la où elle est. - saut vers l'adresse de retour
-- Schmurtz
Cela ne dépend pas de MacOS X, c'est juste la méthode couramment
utilisée. Rien n'empèche de l'enregistrer où on veut.
Et tu expliques comment aux routines (librairies, etc...) que tu
appelles que tu as mis l'adresse de retour ailleurs ?
Pas besion car l'enregistrement de l'adresse de retour n'est utilisé
qu'à l'intérieur de la routine :
- entrée dans la routine
- sauvegarde où tu veux de l'adresse de retour (stoquée dans le registre
LR lors de l'appel)
- plein de trucs (dont des appels de fonctions)
- récupération de l'adresse de retour la où elle est.
- saut vers l'adresse de retour
Cela ne dépend pas de MacOS X, c'est juste la méthode couramment utilisée. Rien n'empèche de l'enregistrer où on veut.
Et tu expliques comment aux routines (librairies, etc...) que tu appelles que tu as mis l'adresse de retour ailleurs ?
Pas besion car l'enregistrement de l'adresse de retour n'est utilisé qu'à l'intérieur de la routine :
- entrée dans la routine - sauvegarde où tu veux de l'adresse de retour (stoquée dans le registre LR lors de l'appel) - plein de trucs (dont des appels de fonctions) - récupération de l'adresse de retour la où elle est. - saut vers l'adresse de retour
-- Schmurtz
Philippe Legroux
Merci pour vos réponses mais je viens de trouver la solution.
Le problème venait d'un strcpy !!!
Ci-dessous le code incrimé (dans la fonction qui plantait la pile d'exécution du programme) :
... strcpy((char*)mes,(char*)"pbla bla..."); ...
(où 'mes' est déclarée comme Str255)
En enlevant 'p' en début de chaîne et en réexécutant le code tout se passe bien !
Apparemment strcpy n'est pas implémenté de la même façon dans les librairies pour Mac OS X et pour Mac OS 9.
Le même code s'exécutait correctement en Mac OS 9 et inférieurs depuis des années.
Philippe.
Merci pour vos réponses mais je viens de trouver la solution.
Le problème venait d'un strcpy !!!
Ci-dessous le code incrimé (dans la fonction qui plantait la pile
d'exécution du programme) :
...
strcpy((char*)mes,(char*)"pbla bla...");
...
(où 'mes' est déclarée comme Str255)
En enlevant 'p' en début de chaîne et en réexécutant le code tout se passe
bien !
Apparemment strcpy n'est pas implémenté de la même façon dans les librairies
pour Mac OS X et pour Mac OS 9.
Le même code s'exécutait correctement en Mac OS 9 et inférieurs depuis des
années.
