GDB: can't exit from itself

[kas1e]

Current GDB can't exit from itself, even enough to run it and type quit immediately to have it all hangs. No cpu loading, no crash. Just nothing happens and nothing on serial.

But, after few seconds, OS4 did bring a warning window with this words:

Parent process has tried to exit before all children have.
Process: "gdb worker"
Function: "Wait_Until_Child_Ends(SHELL)"

Error Process: "New Process" <pid=167>

Then window disappear, but GDB still can't exit and still waiting specific action.

[kas1e]

Some more info:

After some tries, i were able to crash one time when i hit exit (without doing anything, just run and exit), and after ignore DSI usual warning window about Wait_Until_Child_Ends() popup. But i not sure if it related or not .. There are this crashlog:

SPRs (Special Purpose Registers):
           Machine State (msr) : 0x0002F030
                Condition (cr) : 0x66680000
      Instruction Pointer (ip) : 0x0184D784
       Xtended Exception (xer) : 0x60CFC164
                   Count (ctr) : 0x00570001
                     Link (lr) : 0x00000000
            DSI Status (dsisr) : 0x85027002
            Data Address (dar) : 0x6668AA44

Stack trace:
    native kernel module kernel+0x0004d784
    [../../gdb/ppc-amigaos-nat.c:366] gdb:_ZN22ppc_amigaos_nat_targetD2Ev()+0x84 (section 1 @ 0x6E1E3C)
    gdb:_GLOBAL__sub_D_ppc_amigaos_vrregmap()+0x24 (section 1 @ 0x6E537C)
    module LIBS:clib4.library at 0x7E9C69FC (section 0 @ 0x509D8)
    module LIBS:clib4.library at 0x7E9C6F44 (section 0 @ 0x50F20)
    module LIBS:clib4.library at 0x7E9775E8 (section 0 @ 0x15C4)
    gdb:clib4_start()+0x164 (section 1 @ 0x1D2C)
    gdb:_start()+0x30 (section 1 @ 0x1E70)
    native kernel module kernel+0x0005f2b4
    native kernel module kernel+0x0005f32c

PPC disassembly:
 0184d77c: 81240022   lwz               r9,34(r4)
 0184d780: 38600001   li                r3,1
*0184d784: 90a90080   stw               r5,128(r9)
 0184d788: 4e800020   blr               
 0184d78c: 38600000   li                r3,0

[migthymax]

The cause for this is the comment in thread-pool.cc around line 133:

/* The thread pool detach()s its threads, so that the threads will not prevent the process from exiting. However, it was discovered that if any detached threads were still waiting on a condition variable, then the condition variable's destructor would wait for the threads to exit -- defeating the purpose.

Allocating the thread pool on the heap and simply "leaking" it avoids this problem. / thread_pool thread_pool::g_thread_pool = new thread_pool ();

The last line creates the Task. The thread pool is implemented using the 'CXX_STD_THREAD' from the C++ runtime.

As none code modification solution the thread pool of gdb can be implemented as a dummy, which executes the task on the callee context. This is achieve with the configuration option --disable-threading

Hence add that option to the configurecall during building gdb and try please.

[kas1e]

Yes, --disable-threading deal with. Should we close this issue, or keep it open in case to find what exactly problem with threading is ?

[migthymax]

I think we can close this, because this exit problem even occurs with gdb-v. The other exit problems seems to be in combination with running an inferior. And thus the inferior is not "killed" correctly.