Skip to main content
Question

Uv/linux, session LOCKED at Layer stack 0x0000000

  • November 12, 2024
  • 2 replies
  • 0 views
Manu Fernandes
Forum|alt.badge.img+2

Hi

A strange behavior, we have a subr WI.LOG which call another subr GET.PORT which make a simple OCONV(0,'U50BB')

U50BB run fine million times a day. 

Sometime the session seems 'suspended' and PORT. STATUS LAYER STACK return GET.PORT at 0x000000000 ! 

After a while, the system continue...

I suppose its a lock situation ! Semaphore lock ? 

Is someone experience a subr call 'stopped' like this ? 

Adress 0x000000 is strange ? 

Thanks for any comment. 

Manu

BASIC run machine GET.PORT 0x00000000
BASIC run machine WI.LOG 0x00000028

    2 replies

    Mark Baldridge
    • Mark Baldridge
    • Participating Frequently
    • 57 replies
    • November 13, 2024

    Hi

    A strange behavior, we have a subr WI.LOG which call another subr GET.PORT which make a simple OCONV(0,'U50BB')

    U50BB run fine million times a day. 

    Sometime the session seems 'suspended' and PORT. STATUS LAYER STACK return GET.PORT at 0x000000000 ! 

    After a while, the system continue...

    I suppose its a lock situation ! Semaphore lock ? 

    Is someone experience a subr call 'stopped' like this ? 

    Adress 0x000000 is strange ? 

    Thanks for any comment. 

    Manu

    BASIC run machine GET.PORT 0x00000000
BASIC run machine WI.LOG 0x00000028

    Do you have a custom U50BB? A VLIST of WI.LOG and GET.PORT to see what is at address 0x28 and 0x0, respectively, is a good first step.

    While the stack trace may appear stopped, is it accumulating CPU?

    Mark Copp
    • Mark Copp
    • Participating Frequently
    • 14 replies
    • November 14, 2024

    Hi

    A strange behavior, we have a subr WI.LOG which call another subr GET.PORT which make a simple OCONV(0,'U50BB')

    U50BB run fine million times a day. 

    Sometime the session seems 'suspended' and PORT. STATUS LAYER STACK return GET.PORT at 0x000000000 ! 

    After a while, the system continue...

    I suppose its a lock situation ! Semaphore lock ? 

    Is someone experience a subr call 'stopped' like this ? 

    Adress 0x000000 is strange ? 

    Thanks for any comment. 

    Manu

    BASIC run machine GET.PORT 0x00000000
BASIC run machine WI.LOG 0x00000028

    I find the best way to find out what's really going on under the hood is to examine the UNIX process stack using gdb

    *** Be extremely careful if you are not sure what you're doing, especially on Production servers ***

    gdb uvsh [PID]

    Issue the bt (Back Trace command)

    Issue the 'q' (Quit command) to exit, be sure to quit gdb ASAP otherwise there is a risk of impacting other UniVerse sessions

    (gdb) bt
    #0  0x00007fb2de6d8c07 in pause () from /usr/lib64/libc.so.6
    #1  0x00007fb2dff5461f in UVInternalSleep () from /opt/u2/uv/bin/libuniverse.so
    #2  0x00007fb2dfc8ea0e in do_sleep () from /opt/u2/uv/bin/libuniverse.so
    #3  0x00007fb2dfc8eaa9 in zzzzz () from /opt/u2/uv/bin/libuniverse.so
    #4  0x00007fb2dfade10f in clexec () from /opt/u2/uv/bin/libuniverse.so
    #5  0x00007fb2dfc696f2 in startup_continue () from /opt/u2/uv/bin/libuniverse.so
    #6  0x00000000004026c0 in main ()
    (gdb) q
    A debugging session is active.
            Inferior 1 [process 297255] will be detached.
    Quit anyway? (y or n) y
    Detaching from program: /opt/u2/uv/bin/uvsh, process 297255
    [Inferior 1 (process 297255) detached]

    If you see a DB...semp function in the stack then you're likely to attempting to obtain (or could be releasing) a Semaphore but you may also see clues as to why your process is locking up, the top frame (#0) of the stack should detail the specific System Call that is taking place.

    You could also view the System Call stack using the 'cat' command on the /proc/[PID]/stack, but this will not show details of the UniVerse process stack

    # cat /proc/297255/stack
    [<0>] __do_sys_pause+0x30/0x60
    [<0>] do_syscall_64+0x59/0x90
    [<0>] entry_SYSCALL_64_after_hwframe+0x77/0xe1


    Terms & ConditionsAccessibility statement