In the last episode (May 05), David Gourdelier said:
Personnaly I have bugs with FreeBSD regarding process.create_process as show in the Pike farm (http://pike.ida.liu.se/generated/pikefarm/7.6/17_14/verifylog.txt). It
This is a rare (on my system at least) problem that I have not been able to diagnose, and it has been around for ages. I usually get an error of 19 (ENODEV), and nowhere in the kernel is that error returned in the read() codepath. I even added a panic-check to the read syscall. My best guess is that the threads code is somehow corrupting errno or the returnvalue of read() during thread switches. I have only seen this with libc_r threading.
would be good if *BSD can be green. I also have this problem:
/home/david/Pike/7.6/src/threads.c:69: Fatal error: /home/david/Pike/7.6/src/signal_handler.c:1255: pthread_mutex_unlock(&wait_thread_mutex) Unexpected error from thread function: 22 Backtrace at time of fatal: object(src/module.c:61).Builtin()->create_process:
I see this too, more frequently, only with kernel threads (both libthr and libkse, iirc). 22 is EINVAL, and is returned when pthread_mutex_unlock is passed an uninitialized mutex. I've narrowed it down to a problem creating the wait thread created when pike wants to fork(). If the process is not already threaded, the th_atfork call at the top of wait_thread() initializes the parent and child callbacks but not the prepare callback (aka do_da_lock). do_da_lock locks the above mutex, and if it's not called, the child errors out trying to unlock it. If the pike script has already created threads, the call seems to work.