fork never returns to child process

[Sandra R Leung]

I'm encountering a random (about 60% of the time) occurrence with the fork call. Using dde I see the stack trace captured in the attachment. I have searched the patch/firmware database and applied all patches that appear to be related to fork, ksleep, pthreads, libc and multithread. The problem appears to be more frequent with boxes that have more CPUs.

I am running on B11.11

Has anyone encountered anything similar? Or have suggestions for resolving?

[A. Clay Stephenson]

It would probably be useful to install pthread_atfork handlers in the parent and child processes so that you could see what is happening. Man pthread_atfork for details.

My other thought is that the process is executing a non signal-safe function during the fork().

[Jim Butler]

You may be encountering a problem with privs, and may want to add privs to your group. Do a man privgrp (getprivgrp, setprivgrp, /etc/privgroup).

I would add all available privs to your userid, and back them out one at a time.

/sbin/init.d/set_prvgrp start/stop to crank them up = you can read that startup file to figure out the entries needed.

example:
contents of a sample /etc/privgroup

-g CHOWN RTPRIO MLOCK
group1 SETRUGID RTPRIO RTSCHED
group2 RTSCHED


where group1 and group2 are simple groups from your /etc/group file....

10 bucks that solves it for you

[A. Clay Stephenson]

Priviliges would not elicit random behavior. That sould much more like signals to me.

[A. Clay Stephenson]

The other thing that I would like at are tunables like maxuprc, nproc, nkthread, and max_thread_proc. It would be very helpful to know the value of errno after a failed fork().

[Sandra R Leung]

First off thank you all for your prompt responses! Very much appreciated!

I've added a simple handler for the child process that simply spits out some diagnostics at this point. This does seem to alter the frequency of the fork hanging so I'm investigating what other threads are doing at the same time that could be instigating the problem. When the problem happens I can see the diagnostic output from the child fork handler but no thread of control returning to the child process' main code after fork. The call to fork always succeeds for the parent with the pid of the child returned so there is never an errno to look at. I can see two processes created using ps. My application is running in co-operative thread scheduling mode so only a single thread should be "live" at any given time.

And finally, I'm still trying to interpret what it could mean when the stack trace always shows the child process thread stuck in a ksleep call.

[Steven E. Protter]

Taking the view of coming up at the end, if this is a busy system, the last post of A. Clay seems to be where I'd look.

I'd love to see your diagnostics but will be offline when you get them. This system is probably hitting some limits. nproc and maxuprc seem to be the most likely suspects.

SEP

[Sandra R Leung]

I've tried bumping up the kernel parameters to no avail from:

maxuprc 200 Y 200
nproc 4096 - 4096
nkthread 18000 - 18000
max_thread_proc 1024 - 1024

to:

maxuprc 400 Y 400
nproc 8192 - 4096
nkthread 36000 - 18000
max_thread_proc 2048 - 1024

Similarly there are no messages displayed in the syslog.

[Sandra R Leung]

Another thought I had. What are the implications of calling fork() from within a co-operative thread scheduling model? Is it possible that the thread calling fork (and thus the only thread duplicated in the new process) is scheduled to sleep in the duplicated process? Thus never waking up?

[Sandra R Leung]

Just as a follow up here's what's been discovered working with HP support:

One of the fork cleanup routines is trying
to lock a mutex due to a free being called within it. The process uses
TLS so it is nessisary. This mutex is the arena mutex and is at the time of the memory dump unlocked, so it looks like a race condition. It will hang forever.

Increasing the number of arenas in the C-heap with

export _M_ARENA_OPTS=32

had no effect.