I’m using: SWI-Prolog version 8.0.2 on Ubuntu Linux 18.04.
The XPCE debugger (launched via gtrace from the console) is very stable, but every now and then I try something that causes it to be come unresponsive. For example, at least with my current code base, trying to use the debugger option to enter a query on the debugged thread during a paused trace causes it to “hang”.
Is there a way to easily shut down a “stuck” debugger instance? I tried using the System Monitor, but the only useful entry I found in the process list was for the swipl process that spawns it. The problem is, I typically have several SWI-Prolog instances open concurrently and therefore have many instances of the swipl process in the task list, with no way to tell which one spawned the debugger. Currently I have to shut them all down and start them up again just to close the XPCE debugger.
Is there a way for me to get the process ID for the swipl instance that spawned the debugger, so I could shut just it down from the System Monitor process? If not, may I suggest in a future version that the process ID of the owner swipl instance be shown in the window title bar for the debugger? (E.g. - SWI-Prolog debugger:8799, where 8799 could be the current process ID for the swipl instance that launched it).
The debugger is not a separate process, but just an xpce window controlled from the pce thread. If it is really stuck (which should not happen), killing the whole Prolog process is your only option. The PID is available through the Prolog flag pid.
@Jan. Hi Jan. I’m starting to believe there’s a significant conflict between the graphical debugger and the graphics and I/O libraries it uses on my Ubuntu 18.04 box. As I mentioned in another thread, I have minor but frequent repaint issues when I switch over to the graphical debugger. Also, it is relatively easy for me to crash the debugger to the point I have to kill the host swipl process:
^C.
^C
WARNING: By typing Control-C twice, you have forced an asynchronous
WARNING: interrupt. Your only SAFE operations are: c(ontinue), p(id),
WARNING: s(stack) and e(xit). Notably a(abort) often works, but
WARNING: leaves the system in an UNSTABLE state
Action (h for help) ? PID: 830
Action (h for help) ? exit (status 4)
.
^C^C^C
^C.
^C^C^C..
^C.
aaa
.
dkdkdk
(At this point I killed the swipl process using the Process Monitor and the PID I obtained above.
Can you think of any libraries I might purge and (re)-install on my box that might help this? I just did a recent update so I believe I have the latest of everything.
It says so, doesn’t it? Don’t use double ^C except for emergencies. Even the exit from there can easily lead to deadlocks. Typically the way out is to use ^Z to suspend the process and then then kill -9 % to kill the most recent job.
The interesting problem is before that: when do we get stuck such that ^C doesn’t help. That is not totally impossible. It should work when doing normal Prolog computation and when waiting on interruptible blocking system calls. Loops in C without any involved Prolog cannot be interrupted unless they check for interrupts at certain points. There are also some non-interruptible blocking calls such as waiting for a mutex.
Hi Jan. The double Ctrl-C did not create the deadlock. I used it as per the help text because it was an emergency (the debugger and console window were hung and unresponsive). The deadlocks happen when I try to use one of the advanced debugger features that involve making queries while the debugger is stopped on a trace line.
If your code uses mutexes I think it is well possible to create deadlocks that way. If not, it shouldn’t be possible to deadlock. The only way to analyze at this moment is by attaching gdb and get a backtrace for the threads blocked on a lock.
If this happens, figuring out what happened using gdb and report is worthwhile. Otherwise the quickest way out is typically ^Z and then kill -9 % to kill the most recently stopped job.
Thanks. No mutexes. I’ll try gdb. It will take a while since I’ve only done that sort of thing with Visual Studio on Windows and have to learn how to use gdb Perhaps CLion (JetBrains C++ IDE on Linux) can do something similar. I have CLion.