Skip to Content

Debugging the MaxDB Kernel on Unix – How to get a Call stack from hanging tasks

 

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.

 

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.