semop() looks like hanging => Sleeping forever

[Sup]

Hi All,

We are running OCI application againest
Oracle 8.1.6 on HP 11. The application seem to be hanging/sleeping forever at semop() system call. We killed this application wil kill -11
to get a core file but "gdb -c core" not telling anything to us. We ran the OCI application under "tusc" debugger and found out application hanging at semop() system call.
Is there is any patch available to this problem..

tusc output

read(7, "\0Q \0\006\0\0\0\0\0\b\0021ccc/ ".., 1516) . = 81
write(7, "\015\0\006\0\0\0\0\00305\r\0\0\0".., 21) .. = 21
read(7, "\0a \0\006\0\0\0\0\00602\001\0\0".., 1516) . = 97
write(7, "\011\0\006\0\0\0\0\003140e\0\0\0".., 17) .. = 17
read(7, "\0\v\0\006\0\0\0\0\0\t", 1516) ............. = 11
alarm(10) ........................................... = 0
sigvec(SIGALRM, 0x73817228, 0x73817238) ............. = 0
time(NULL) .......................................... = 1040576552
sigtimedwait(0x73816c50, NULL, 0x73816c70) .......... ERR#11 EAGAIN
time(NULL) .......................................... = 1040576553
semop(213330, 0x73816b38, 1) ........................ [sleeping]

After this process was doing nothing..

Some HP patchs are also installed

PHNE_19899 1.0 cumulative ARPA Transport patch
PHNE_20150 1.0 Cumulative Mux and Pty Patch
PHSS_16839 1.0 Assembler patch.
PHSS_16849 1.0 LIBCL patch
PHSS_17421 1.0 XClients JAN 99 Cumulative Patch
PHSS_17980 1.0 ImagingSubsystem April 1999 Periodic Patch
PHSS_20140 1.0 CDE Runtime OCT99 Cumulative Patch
PHSS_20141 1.0 Xserver cumulative patch
PHSS_20142 1.0 X/Motif2.1 Runtime OCT99 Cumulative Patch
PHSS_20146 1.0 Firmware update for B1000, C3000 and J5000
PHSS_21046 1.0 OV EMANATE14.2 Agent Consolidated Patch
PHSS_21947 1.0 ld(1) and linker tools cumulative patch
gzip 1.2.4a gzip
openssh 2.5.1p1 openssh
openssl 0.9.6 openssl
perl 5.6.0 perl
zlib 1.1.3 zlib

Any help? Thanx in advance..

[Martin Schneider_2]

I don't mean to sound like a Windows user, but have you tried rebooting? Maybe all the semaphores have been eaten up by old processes.

Before that, try and look at the kernel parameters. Use SAM to locate esp. the SEMMNS setting. It defaults to 128 which is too low for Oracle. The Oracle documentation is pretty explicit about the necessary kernel paramters.

Good luck, Martin

[Dietmar Konermann]

Of course the semop() function is designed to block under certain conditions. This is in fact the syscall's core functionality... synchronization of IPC. See man semop(2).

You need to know the specific context to determine if the blocking is correct or not. Problems in this area are most often caused by the application, not the OS.

Best regards...
Dietmar.