choper les stackoverflow sous morphos/gcc
-
Je cherche à savoir si il est possible de créer sous Morphos/GCC un programme avec une fonction appelée lorsque un dépassement de pile arrive ?
Dans la même idée, j’ai voulus déà voir si -mstackextend marchait, mais je me suis pris une violente erreur du linker comme quoi il ne trouve pas le symbol __stkext1… (ce symbol n’existe à priori pas dans les .a et .o du SDK…!!)
PS: pourquoi choper les stackoverflow?
tout simplement parcque j’aimerai retourner à l’utilisateur de mon programme un message d’erreur lui disant d’augmenter la stack (où alors au moins augement automatiquement et avertir l’utilisateur que cela à été fait)
[edit]
J’ai été mauvaise langue sur le MDC… Merci Henes et CISC pour les réponses. Maintenant j’attend que CISC me fournisse un code d’exemple pour résoudre mon pb…
[/edit]
Mais nico, je suis étonné, je crois me souvenir que tu avais dit dans un autre thread que mos, sans avoir une gestion de pile « finale », possédait déjà quelques fonctions de gestions de dépassements de la pile. Hors c’est justement la fonctionnalité que yomgui demande: un callback lors d’un overlow.
cool je sers d’intermédiaire entre l’equipe mos et yomgui .
Bon, ben voilà yomgui: lis la doc y disent.
(… ou fait une fonction qui va tester la distance jusqu’au pattern annonçant la fin de la pile.)
ptain fo tout leurs faire.
Attention avec cette methode le jour ou la pile sera géré ça va exploser la machine… mais ça n’arrivera pas. Rapelle toi que le blender que tu fais sera adapté pour un contexte ABox et pas QBox.
>lis la doc y disent
Pas la peine, il suffit qu’il lise le forum de dev morphos où il lui a
déjà été répondu en détail.
>ou fait une fonction qui va tester la distance jusqu’au pattern
>annonçant la fin de la pile
Un tel pattern n’existe pas. Il serait absolument pas efficace
d’utiliser cette méthode qui obligerait à parser jusqu’à plusieurs
megaoctets de mémoire suivant la taille de la pile.
Il suffit d’utiliser les champs dédiés dans struct Task. Il indiquent
l’emplacement de la pile, sa limite et la position actuelle.
>ptain fo tout leur faire
ptain faut toujours rectifier derrière toi
>Attention avec cette méthode le jour ou la pile sera géré ça va
>exploser la machine… mais ça n’arrivera pas
Effectivement, cela n’arrivera pas pour la simple et bonne raison que
marquer une page à la fin de la pile et compter dessus pour détecter
les stack overflow ne fonctionne pas dans les cas où on utilise la
mémoire située après.
Ainsi, il est impossible de détecter ce type de cas:
char *a[PAGE_SIZE]; a[PAGE_SIZE]=0;
Ceci couvre la technique que sg2 avait annoncée être utilisée dans
OS4.
Marquer toutes les pages suivantes comme le font tous les autres
systemes est bien évidemment impossible vu que les programmes amigaos
doivent se partager la meme zone d’adressage jusqu’à la fin des temps.
Et de toute façon, même si cela était possible, il ne serait pas
possible d’agrandir sur place la pile puisqu’une autre appli peut
utiliser les addresses mémoire nécessaires.
Donc, une fois ça marcherait, une fois ça marcherait pas et le truc
planterait. Bravo l’instabilité aléatoire contre laquelle
l’utilisateur et le programmeur ne peuvent rien faire.
Laisser l’OS automatiquement détecter les dépassements de pile et y
rémédier est impossible dans un environement amigaos comme tout le
monde le sait.
Reste la solution qui a été expliquée à yomgui sur le forum de dev
morphos et qu’il avait déjà trouvé tout seul de toute façon.
La drogue c’est mal (et illégal).
>Et de toute façon, même si cela était possible, il ne serait pas
>possible d’agrandir sur place la pile puisqu’une autre appli peut
>utiliser les addresses mémoire nécessaires.
De toute façon, c’est tellement plus simple de tester son programme en
profondeur et de mettre par défaut suffisament de pile…
__long stack = APPROPRITE_STACKSIZE; // Et voila
Nico a écrit :
Tu peux inserer en global:
long __stack = MY_STACKSIZE;
De cette façon, le startup code modifera la pile automatique au
lancement de l’application.
Il y a aussi exec.library/StackSwap().
Bye
Je connais, je connais je fait ça depuis longtemps
Mais il faut savoir en faite que Python gére un système d’exceptions comme sur Java pour les erreurs. Et une particulière est MemoryException qui arrive lorsque il n’y a plus de mémoire pour les allocations ou lors des stackoverflow.
Ainsi cela permet au programme de ne pas planter (et le système avec) et d’opérer les opérations ad-hoc pour gérer cette exception (sortir correctement, réalloué de la stack, etc… mais surtout pas cracher la machine!!!)
Je veux donc mettre cette fonctionnalité dans mon port de Python. voilà le pkoi du tout …
/me personnellement contre l’allocation statique de la stack
Pour henes:
>Marquer toutes les pages suivantes comme le font tous les >autres
>systemes est bien évidemment impossible vu que les >programmes amigaos
>doivent se partager la meme zone d’adressage jusqu’à la fin >des temps.
>Et de toute façon, même si cela était possible, il ne serait >pas possible d’agrandir sur place la pile puisqu’une autre >appli peut utiliser les addresses mémoire nécessaires.
Tu résonnes en terme de mémoire linaire (année 80, culture amiga classique). Du point de vue d’une tache protégé lespace adressable est une « matrice » de la mémoire réelle.
on peut avoir une partie de l’espace d’adressage commun d’une part et privée d’autre part. dans l’adressage commun on peut avoir des plages en lecture/écriture pour une tache et en lectures seule pour une autre. (l’exeption d’écriture étant géré de telle ou telle façon.) c’est dingue on peut faire vachement de truc en informatique tu crois pas ?
>Ainsi, il est impossible de détecter ce type de cas:
>char *a[PAGE_SIZE]; a[PAGE_SIZE]=0;
pour info la pile « recule » elle n’avance pas. ton exemple trashe la pile déjà alloué. tu as voulu dire:
char *a[PAGE_SIZE]; a[-1]=0;
Donc les gens qui ne se drogue pas et on une « réputation » informatique solide se trompent aussi tu vois.
pour info la pile « recule » elle n’avance pas. ton exemple trashe la pile déjà alloué. tu as voulu dire:
char *a[PAGE_SIZE]; a[-1]=0;
Donc les gens qui ne se drogue pas et on une « réputation » informatique solide se trompent aussi tu vois.
Si je peux me permettre…
L’exemple d’Henes est le bon, même si initialiser le premier élément du tableau est de l’overkill puisque ça ne fait que dupliquer l’effet obtenu par la création d’une nouvelle trame sur la pile.
En revanche, écrire « a[-1]=0 » est clairement un bug dont la finalité est d’écraser quelque chose, mais personne ne sait exactement quoi
Tu résonnes en terme de mémoire linaire (année 80, culture amiga classique). Du point de vue d’une tache protégé lespace adressable est une « matrice » de la mémoire réelle.
on peut avoir une partie de l’espace d’adressage commun d’une part et privée d’autre part. dans l’adressage commun on peut avoir des plages en lecture/écriture pour une tache et en lectures seule pour une autre. (l’exeption d’écriture étant géré de telle ou telle façon.) c’est dingue on peut faire vachement de truc en informatique tu crois pas ?
En faite Krabob je crois qu’Henes voulais dire que ce n’est pas faisable aujour’hui en gardant le maximum de compatibilité à l’exécution des appli Amiga standard.
Mais bien-sûr, protéger la mémoire d’une tâche sur un PPC est possible… si l’OS+le code généré le gére!
Si je peux me permettre…
L’exemple d’Henes est le bon, même si initialiser le premier élément du tableau est de l’overkill puisque ça ne fait que dupliquer l’effet obtenu par la création d’une nouvelle trame sur la pile.
En revanche, écrire « a[-1]=0 » est clairement un bug dont la finalité est d’écraser quelque chose, mais personne ne sait exactement quoi
merci, et aprés on me fait une réputation….
l’exemple d’henes écrit sur la pile « vieille », alors qu’il voulait écraser coté neuf », il s’est donc gourré: il voualit ecrire coté « pile neuve ».
quand tu alloue une table en pile, il fait un equivalent de:
pile = pile – tailledeletable
table = pile
les prochaine memoire a prendre en pile commence donc à pile-1 et va en arriere.
henes tape dans:
table[tailledeletable] pour figurer un dépassement de pile. mais non, c’est un dépassement de table , c’est fondamentalement différent.
Il efface la pile vielle qui est déjà techniquement alloué, et posséde déjà un sens pour le programme. ce n’est pas « la prochaine memoire disponible en pile ».
Et merci, j’ai 10 ans d’asm a mon actif aussi , en 68k et PPC.
En revanche, écrire « a[-1]=0 » est clairement un bug dont la finalité est d’écraser quelque chose, mais personne ne sait exactement quoi
C’est ce qu’il voulait faire pour montrer un cas que OS4 ne peut (d’aprés lui) pas gérer (un depassement de pile de plus d’une plage memoire.)
Par contre ,kakace ce que tu dis semble montrer que tu pense que
table[tailletable]=0 . est exact… c’est une erreur de débutant.
sans commentaire… pourtant moi qui pensait que tu étais sérieux…
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › choper les stackoverflow sous morphos/gcc