Debugging in GTKIDE

When I'm debugging using the gtk-built IDE and I hit Stop to cancel the debug, the debugged application goes mental, sucking up cpu-time and memory until I kill it.

Not sure where to start looking even... it's like the process doesn't like the fact that we've told it to stop, and it's stomping its feet in protest.

Other than that, *cough*, I can use the gtk-IDE without problem...

hmm... seems to be when this line is executed :
TProcess.Close()...

		If pipe pipe.Close;pipe=Null

..debugging is fun... (not)...

This is my test :

SuperStrict

Print "Hello"

DebugStop

Local i:Int = 10

For Local n:Int = 1 To i
	Print n
Next

The first part is running an App in debug from GTK IDE :

Okay... I attached strace to the debugged app.
While paused (at the DebugStop) it appears to generate lots of

--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])

which I can only assume is a timer.

When I hit Stop / Halt (the red button), I get an endless repeating of:

read(0, "", 4096)                       = 0
write(2, "~>\n", 3)                     = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
read(0, "", 4096)                       = 0
write(2, "~>\n", 3)                     = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
read(0, "", 4096)                       = 0
write(2, "~>\n", 3)                     = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---

interspersed with occasional SIGALRM.

Right, I did the same thing from the FLTK IDE...
The app executes, and stops at the DebugStop. I the run strace on the app PID, and while paused it generates the same as before - lots of SIGALRMs.
However, when I press Stop in the IDE, I get this instead :

--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
write(2, "~>StackTrace{\n", 14)         = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
Process 20070 detached

As soon as it gets a "Broken pipe", it halts.

So the question is, what is causing the GTK-started debug not to stop at the same point?

:-(

It might be worth waiting until skid is back off holiday, but I've had a few rummages in the debugger myself.

It looks like there is a difference between the "normal" and GTK versions from your description - the normal one is just kicking out "~>", while the GTK one is kicking out "~>StackTrace{" and then dying.

My (vague) understanding of the debugger is that a "~>" is the debug code inside the app (appstub.bmx I think) indicating it's got no output to return the debugger (IDE) and is ready for new input. "~StackTrace{" should be the start of a whole slew of returns giving data on where the code has broken out, app state and variable states.

As such, my guess is that the internal debug code (appstub.bmx, not the IDE) is trying to dump the stack but getting confused over something in the stack and stopping dead. As this only happens under GTK, presumably the code is trying to interrogate a GTK object / function and failing. But then your test app doesn't use GTK or FLTK...

I'm not sure that helps much - you may well have already figured the above for yourself - but I think I'd first check that both outputs do generate a "StackTrace{", then if they do, ascertain what it is that works under FLTK, but presumably isn't under GTK.

It's all interesting stuff, this linux malarky.

I wonder if GTK installs something to ignore the SIGPIPE, as from all I've read, the default SIGPIPE-ness is to terminate an app.

On more reading, I decided that perhaps I needed to install a SIGPIPE handler to make it exit - on the assumption that if it wasn't quitting it should be.

appstub.linux.c has these in main() :

	signal( SIGBUS,sighandler );
	signal( SIGSEGV,sighandler );
	signal( SIGTERM,sighandler );
	signal( SIGTRAP,sighandler );

so I added my own handler...

static void sigpipeHandle( int n ){
	exit(0);
}

and then in main() added :

signal( SIGPIPE,sigpipeHandle );

and wouldn't you know... it works :-D

And as far as I can see, since linux apps should terminate on a SIGPIPE *anyway*, having this built-in as standard shouldn't be an issue???

Anyhoo... learned all about signals today, so at least I've done something useful.

@Mark, I think I might have a bash with the CE IDE now... and see how I get on ;-)

Good to hear you got it sussed, it does indeed sound like the right fix. Have fun with the CE IDE. Note that in the CVS there are two versions now. maxide = current version plus a few bugfixes, and maxide2 which is where we're making more fundamental changes.

Also, if you've got your head around the debugger code, I'd appreciate your thoughts on being able to force a debugstop at any time from the IDE. It seems fairly easy to do this inside appstub.bmx, but I just didn't understand the inter-process communication stuff, and so couldn't figure out how to get the IDE to tell the app to stop midflow (or even if it were possible). Any ideas?

an update...

instead of requiring a new handler function, you can in fact simply add:

signal(SIGPIPE, SIG_DFLT);

which tells it to use the "default" handling.

Mark, I believe I have a way to "pause" a running app in debug mode :-)
However, it will only work on linux/OSX because it would use a signal to make the running app call OnDebugStop() - which as I've discovered, signals aren't supported on windows.

Still... it's nice if you like that kind of thing - and since my dev time is currently spent almost entirely in linux at the moment, it would be useful at least to me :-)

cool!

dagnabbit!

There must be some way to do it in win, just differently. And it was exactly this "signalling" that I kept getting stuck at when I looked at it before, because it really did look like all you needed to do was call OnDebugStop() on receiving the signal.

I wonder if Mr Sibly or Mr Armstrong have any suggestions...

The only thing I can think of would be to have some kind of "message" thing happening on win32, but win32-api hacking is out of the scope of my other brain-cell.

I might have a play with the linux-side over the weekend and see how I get on, braai's permitting... :-)