Invoking the hotspot gdb helper functions such as help() and pns() from debug.cpp segfaults when executed on a detached thread, such as the first thread of the process which gdb lands on with a break.

Executing the innocent looking command "call help()" on a detached thread can cause JVM to execute error reporting and the process will not continue executing, resulting in losing a possibly valuable debug session.

The crash is caused by an assertion failure in Thread::current(): "Thread::current() called on detached thread", which is triggered by the ResourceMark constructor in the Command object. Note that Command object has a DebuggingContext for temporarily disabling assertions but it is initialized after ResourceMark.

One way to fix it is to reorder the DebuggingContext field and add checks to the Command class of the expected thread type via new bool onAttachedThread(), bool onJavaThread() methods.

Helper functions would then check for the required thread state. when not matched would print a warning and return without crashing.

Furthermore, we can add documentation to the help() about which thread state is required per command.