910843_fr-FR

liliconcom

L'appel à Throw() avec l'indicateur de traceback dans une sous-fonction provoque un plantage de JMP.

J'ai rencontré le problème suivant (exemple minimal ci-dessous). S'agit-il d'un bug ou ai-je oublié quelque chose ?

(Windows 11, JMP 18.0)

Le script suivant provoque le plantage de JMP au lieu de simplement générer une erreur :

Names Default To Here(1);

f = Function( {}, { sub_f },

	sub_f = Function( {},
		If( 1, Throw( "thrown", 1 ) );			
		Return( "ok" )
	);
	
	Return( sub_f() )
);

f()

Contrairement à ce qui précède, sans l'indicateur de traceback, il génère normalement l'erreur « levée ».

Names Default To Here(1);

f = Function( {}, { sub_f },

	sub_f = Function( {},
		If( 1, Throw( "thrown" ) );			
		Return( "ok" )
	);
	
	Return( sub_f() )
);

f()

De plus, le plantage est évité en interceptant la fonction Return() dans Try().

Names Default To Here(1);

f = Function( {}, { sub_f },

	sub_f = Function( {},
		If( 1, Throw( "thrown", 1 ) );			
		Return( "ok" )
	);
	
	Try( Return( sub_f() ), Throw( "crash prevented" ) )
);

f()

Automatisation et scriptageRe : Throw() avec l’indicateur de traceback dans une sous-fonction provoque un plantage de JMP

Vous avez trouvé un bug dans JMP. Je soumets un rapport renvoyant à cette discussion. Vous pouvez contourner le problème en commentant la variable locale pour sub_f :

f = Function( {}, // { sub_f },

(Je suis presque certain que c'est une explication correcte...) Au moment où JMP intercepte l'appel à `throw()`, les variables locales sont détruites et les informations nécessaires à la trace d'exécution sont perdues. Le code qui génère cette trace n'est pas préparé à cela et plante avec une référence mémoire invalide. En ajoutant `try()` à l'intérieur de la fonction, JMP intercepte l'appel à `throw()` à l'intérieur de celle-ci et la variable locale n'est pas détruite. Vous pouvez aussi simplement définir la fonction dans une variable globale.

modification : TS-00250890