910843_es-ES

liliconcom

La función `throw()` con la bandera de seguimiento de pila dentro de una subfunción provoca un fallo en el salto del monitor.

Me he encontrado con el siguiente problema (ejemplo mínimo a continuación). ¿Es un error del juego o me estoy perdiendo algo?

(Windows 11, JMP 18.0)

El siguiente script provoca un fallo en JMP en lugar de simplemente mostrar el error:

Names Default To Here(1);

f = Function( {}, { sub_f },

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

f()

En contraste con lo anterior, sin el indicador de seguimiento de pila, normalmente lanza el error "thrown".

Names Default To Here(1);

f = Function( {}, { sub_f },

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

f()

Además, se evita el fallo atrapando el Return() en 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()

Automatización y scriptingRe: El uso de Throw() con la bandera de seguimiento de pila dentro de una subfunción provoca un fallo en JMP

Has encontrado un error en JMP; estoy enviando un informe que enlaza a este hilo. Puedes solucionarlo comentando la variable local para sub_f:

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

(Creo que esta explicación es bastante acertada...) Para cuando JMP intercepta la excepción `throw()`, las variables locales ya se han destruido y se ha perdido la información para el seguimiento de la pila. El código que genera el seguimiento no está preparado para esto y falla con una referencia a memoria no válida. Al agregar el bloque `try()` dentro de la función, JMP intercepta la excepción dentro de la función y la variable local no se ha destruido. O bien, simplemente mantener la función en una variable global también funcionará.

edición: TS-00250890