Eric Blake wrote: > According to Johan van Selst on 3/1/2010 11:02 AM: > > Sure, it's now up on http://mud.stack.nl/~johans/193-ktrace.txt > > (output from the test in checks/193.esyscmd) > Actually, it looks like you posted the trace for 007.command_li
Oops, I was rather hurried when posting this: it was 007.command_li indeed. There is now a new http://mud.stack.nl/~johans/193-ktrace.txt and http://mud.stack.nl/~johans/007-ktrace.txt (both with child tracing) for reference. This quickly identifies a problem: 2143 gm4 CALL sigprocmask(SIG_BLOCK,0x545a20,0) 2143 gm4 RET sigprocmask 0 2143 gm4 CALL vfork 2144 gm4 RET fork 0 2144 gm4 CALL sched_setscheduler(0,<invalid=0>,0x800a0e918) 2144 gm4 RET sched_setscheduler -1 errno 1 Operation not permitted 2144 gm4 CALL exit(0x7f) 2143 gm4 RET vfork 2144/0x860 2143 gm4 CALL sigprocmask(SIG_UNBLOCK,0x545a20,0) 2143 gm4 RET sigprocmask 0 The issue seems to be with the seconds argument of sched_setscheduler() Quoting the FreeBSD <sched.h> there is no argument defined as 0 - Ref. http://cvsweb.freebsd.org/src/sys/sys/sched.h /* POSIX 1003.1b Process Scheduling */ /* * POSIX scheduling policies */ #define SCHED_FIFO 1 #define SCHED_OTHER 2 #define SCHED_RR 3 struct sched_param { int sched_priority; }; On FreeBSD the default seems to be SCHED_OTHER (2); whereas on Linux this SCHED_OTHER is defined as 0. It may be that some code relies on this value being 0 and doesn't explicitly set it as SCHED_OTHER. But I haven't really analysed this code and should probably stop guessing and leave debugging to those more familiar with m4. Johan
pgpbAEfwD3vRX.pgp
Description: PGP signature