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?
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
