A colleague of mine has done a very interesting blog entry that deals with MaxDB Kernel debugging on windows:
[Debugging the MaxDB Kernel on Windows - How to get a Call stack from hanging tasks | Debugging the MaxDB Kernel on Windows - How to get a Call stack from hanging tasks]
I will now try to give a more UNIX orientated view on this topic. The following test case was done with 7.6.03 Build 9 on Linux x86_64.
For the sake of simplicity, I have set the parameter USE_COROUTINES to 'NO'.
My test database is very small, therefore, after a few inserts, I am running into a DB FULL situation:
x_cons M76 show active
SERVERDB: M76
ID UKT UNIX TASK APPL Current Timeout Region Wait
tid type pid state priority cnt try item
T214 7 12987 User 13031 DB FULL (197) ! 0 0 150(s)
We now want to investigate what this user task (which is technically a thread) is doing at the moment. So the first step would be to find out in which process's address space this particular thread is running. As a matter of fact, all tasks are running in the MaxDB kernel process.
On UNIX, we typically see two kernel processes:
ps -ef | grep kernel
sdb 12748 1 0 16:57 ? 00:00:00 /sapdb/M76/db/pgm/kernel M76
sdb 12753 12748 16 16:58 ? 00:00:40 /sapdb/M76/db/pgm/kernel M76
Now, let's have a look into these processes in order to find out what they are doing by calling gdb. First of all, we examine the father process:
gdb
(gdb) attach 12748
Reading symbols from /sapdb/M76/db/pgm/kernel...done.
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
Reading symbols from /lib64/tls/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 182905168864 (LWP 12748)]
[New Thread 1075841376 (LWP 12751)]
Loaded symbols for /lib64/tls/libpthread.so.0
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/tls/librt.so.1...done.
Loaded symbols for /lib64/tls/librt.so.1
Reading symbols from /usr/lib64/libstdc+.so.5...done.<br />Loaded symbols for /usr/lib64/libstdc+.so.5For further explanations, you can refer to Debugging the MaxDB Kernel on Windows - How to get a Call stack from hanging tasks.
It can be seen in the x_cons output that the kill flag :!: is set for this user task. Even if we add a data volume now, the insert that was executed will be terminated as soon as the 'loop' that waits for the semaphore (semop) is exited.
