forum-msg-id-136753-edit
Original date:2022-02-27 04:42:43 Edited by: abuaf Subject: Re: BREAKing into Euphoria
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
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
|
