OpenEuphoria

Re: BREAKing into Euphoria

• Posted by abuaf Feb 27, 2022
• 1309 views

// 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; 
	} 
	... 

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 

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. Alternatively we can ask "Is there any other eu libs/code etc that handles win32 callback events - eg win32 sound multimedia playback callback from a buffer? Eg EuSDL2-master but i think the sound is fully handled in the C DLL. If a euphoria sound buffer fill callback supported then this can be tested. IUP must be doing this because as it uses the winProc gui callback originating in the DLL and then propogating to eu callbacks. But maybe they cheat and queue this type of callback, and do polling in euphoria code to dispatch the eu callback safely from euphoria. Someone want to check all this?