Skip to Content

 

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.

 

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply