forum-msg-id-136753-edit

Original date:2022-02-27 04:42:43 Edited by: abuaf Subject: Re: BREAKing into Euphoria

ghaberek said...
ghaberek said...

I plan to look more at the debugging features later

So much for that, I already figured it out. Turns out it was pretty easy, but I'm still not sure how safe this is. The SIGINT (Ctrl+C) signal interrupt handler is configured in InitExecute(). The first step was to borrow some code from trace_command() and plop that into INT_Handler().

// be_rterror.c:1668 
void INT_Handler(int sig_no) 
/* control-c, control-break */ 
{ 
	UNUSED(sig_no); 
	if (trace_enabled) { 
		/* start tracing */ 
		signal(SIGINT, INT_Handler); 
		TraceOn = TRUE; 
		color_trace = TRUE; 
#ifdef _WIN32 
		show_console(); 
#endif 
		return; 
	} 
	... 

This worked great... when with trace was enabled. Turns out trace_enabled is always set to TRUE and the backend relies on the frontend to emit the necessary tracing ops. So my trick would act like allow_break(FALSE) without trace enabled.

I'm not sure why you have conditioned TraceOn with " if (trace_enabled) {" . Does then mean Ctrl-C gets ignored when in "without trace" code sections? If this is the case, then this defeats the objective of a debugger allowing interruption of the program. What is desired is defferal (queuing) of the interruption until the next "with trace" section. Can you test this by adding a loop in "without trace" section and pressing break while there in the code below?

include std/os.e 
 
without trace 
function untracable() 
   puts(1, "Untraceable press break now") 
   sleep(4) 
end function 
 
with trace 
 
atom t0 = 0 
atom t1 = time() 
atom t2 = t1 + 60 
 
while t1 < t2 do 
 
    if t1 > t0 then 
        t0 = t1 
        ? t0 
    end if 
 
    sleep(rand(10)/100) 
    t1 = time() 
    untracable() 
end while 
ghaberek said...

This is a pretty neat feature to have, but I'll say it again loudly: I don't know enough about the interpreter yet to say how safe this is. Your app might crash. Weird things might happen.

-Greg

I modified eu 3.1 DOS source to do this about 10 years ago on a big program, never any problem. In a way it cannot cause a problem, since it doesnt modify eu byte code execution in any way other than what it originally is designed to do. The break-key win32 event callback occurs in the backend; this already happens and is compeletely normal and C thread safe since it happens in C. The issue is "is it safe to run a eu callback from a win32 event thread callback (in the backend)?" To really test this, need to run a eu CRC routine while a high-frequency win32 multimedia timer event is firing. The aim is to test arbitrary eu byte code execution interruption - even during partial execution of a byte code - because that is what will happen. I suspect this is not safe, unless the eu callback dispatch code has special byte code thread saving. I havent examined the code for many years, but 99% doubt it has any thread saving. But you never know. This is why i originally used ASM to sidestep this uncertainty.

Not Categorized, Please Help

Search



Quick Links

User menu

Not signed in.

Misc Menu