Page History
All platforms
<SUBSYS>_DEBUG_WAIT
When <SUBSYS>_DEBUG_WAIT is true, a daemon will pause on startup, running a loop of bool debug_wait=1;while(debug_wait){sleep(1)};. That way you can attach to the daemon with a debugger and continue the run.
Note that as of June 18, this doesn't work well on at least some branches as debug_wait gets optimized out. See #3064 for details. You might be able to "jump daemon_core_main.cpp:2046" (check the line number for your code!), but it appears dodgy.
On Windows you might prefer the slightly more convenient <SUBSYS>_WAIT_FOR_DEBUGGER, documented below.
GDB specific issues
clone(), gdb internal-errors
Condor uses clone in a way that causes GDB grief. Running a Condor daemon under GDB will likely fail with errors similar to:
warning: Can't attach LWP -1: No such process ../../gdb/linux-thread-db.c:389: internal-error: thread_get_info_callback: Assertion `inout->thread_info != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)
The solution is to tell Condor to not to use clone, but to fall back on the fork code path. In your Condor configuration file, use:
USE_CLONE_TO_CREATE_PROCESSES = false
(This page primarily exists as search bait, so that others hitting this error can quickly find the solution.)
For the adventurous (or those who are debugging the clone calls), one can apply the patch found on #2208
Windows specific issues
<SUBSYS>_WAIT_FOR_DEBUGGER
In addition to <SUBSYS>_DEBUG_WAIT, on Windows (#ifdef WIN32) you have access to <SUBSYS>_WAIT_FOR_DEBUGGER. It's very similar, but is smart enough to automatically detect when a debugger is attached.