choper les stackoverflow sous morphos/gcc

[Yomgui]

Yomgui

#1192

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]

[lugduweb]

lugduweb

#28917

je ne sais pas répondre à ta question mais tu peux peut etre contourner le problème en la positionnant directement à la bonne valeur (celle qui marche chez toi) en lancant ton programme (y’a pas moyen de positionner ça dans le .info d’ailleurs ?)

[Yomgui]

Yomgui

#28918

En faite j’évite juste le crash… c’est quand même pas bien de crasher, même si c’est pas la faute du programmeur

[anonyme]

anonyme

#28919

@Yomgui:

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

[krabob]

krabob

#28920

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.

[anonyme]

anonyme

#28921

@Krabob: -> [ ]

Il y a quelques extensions pour la pile, lis la doc et poste apres.

Bye

[krabob]

krabob

#28922

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.

[henes]

henes

#28923

@krabob

>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).

[anonyme]

anonyme

#28924

>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

[Yomgui]

Yomgui

#28925

Nico a écrit :

@Yomgui:

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

[Yomgui]

Yomgui

#28926

Merci mon petit krabob de t’inquiéter pour moi

Je lis les docs t’inquiéte… mais pas toute car sinon je ne programmerais jamais

[krabob]

krabob

#28927

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.

[kakace]

kakace

#28928

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

[Yomgui]

Yomgui

#28929

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!

[krabob]

krabob

#28930

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…