My company has a product that allows customers to execute unix commands from within it. Our earlier version used the C function fork( ) to fork the new process, and one customer successfully used prince version 10.7 on Debian using this setup.

We've recently released a new version of our product that now uses vfork( ) to spawn the process, and the prince process now blocks on a semaphore without ever returning. Upgrading to the newer prince 11.3 makes the problem go away.

Any ideas on what caused the older version to hang, and why 11.3 resolves this? Our customer is concerned its a problem with vfork( ).

gdb stack trace of the hanging prince 10.7 process looks like:

(gdb) where
#0 0x00007fb21241c827 in futex_abstimed_wait_cancelable (private=0,
abstime=0x0, expected=0, futex_word=0x1282940)
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1 do_futex_wait (sem=sem@entry=0x1282940, abstime=0x0)
at sem_waitcommon.c:111
#2 0x00007fb21241c8d4 in __new_sem_wait_slow (sem=0x1282940, abstime=0x0)
at sem_waitcommon.c:181
#3 0x00007fb21241c97a in __new_sem_wait (sem=<optimized out>) at sem_wait.c:29
#4 0x0000000000907fd6 in ?? ()
#5 0x00000000008f7e4c in ?? ()
#6 0x00000000008f88de in ?? ()
#7 0x00000000008f948c in ?? ()
#8 0x00000000008f96a2 in ?? ()
#9 0x000000000090534f in ?? ()
#10 0x0000000000909067 in ?? ()
#11 0x000000000090956d in ?? ()
#12 0x00000000007bde9e in ?? ()
#13 0x000000000059b66a in ?? ()
#14 0x000000000059bd23 in ?? ()
#15 0x000000000059c2e6 in ?? ()
#16 0x0000000000469826 in ?? ()
#17 0x000000000042c4a5 in ?? ()
#18 0x000000000042c758 in ?? ()
#19 0x000000000042c57c in ?? ()
#20 0x000000000042c758 in ?? ()
#21 0x000000000042c57c in ?? ()
#22 0x000000000042c758 in ?? ()
#23 0x00000000004afdaf in ?? ()
#24 0x0000000000443c6a in ?? ()
#25 0x00000000004441d0 in ?? ()
#26 0x000000000077b6bd in ?? ()
#27 0x00000000004435b8 in ?? ()
#28 0x000000000077aba5 in ?? ()
#29 0x000000000077ac57 in ?? ()
#30 0x000000000077c73f in ?? ()
#31 0x00000000004444b4 in ?? ()
#32 0x00000000004a0c96 in ?? ()
#33 0x00000000004a0e5f in ?? ()
#34 0x000000000077b6bd in ?? ()
#35 0x000000000049e538 in ?? ()
#36 0x000000000077aba5 in ?? ()
#37 0x000000000077ac57 in ?? ()
#38 0x000000000077c13f in ?? ()
#39 0x00000000004a0fc1 in ?? ()
#40 0x00000000004a1265 in ?? ()
#41 0x00000000008f59d2 in ?? ()
#42 0x0000000000409f81 in ?? ()
#43 0x00007fb2106a5830 in __libc_start_main (main=0x409f60, argc=7,
argv=0x7ffe35267198, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7ffe35267188)
at ../csu/libc-start.c:291
#44 0x0000000000409fc9 in ?? ()
(gdb)

Prince uses some UNIX signals which can be blocked by the parent process; Prince 11.3 explicitly unblocks all the needed signals, but you can handle this for older versions of Prince by using pthread_sigmask to unblock any signals your process has blocked before calling exec.

Thanks Mike, appreciate the info.

Hey Mike,

Sorry to bother you again, but our C developer wants to know what specific signals are being unblocked in 11.3. Apparently our signal handling is pretty convoluted, with some being blocked on our side as part of getting the whole vfork( ) mechanism to work properly, so he would like to know the specific signals used by Prince.

Thanks for the info,

Bill.

SIGPWR and SIGXCPU should be sufficient; they are used by the Boehm garbage collector to synchronise threads.

Thanks, Mike. Hopefully that will keep our developer satisfied.

Bill.