Hi,

first a disclaimer: I'm in no way a kernel-hacker and maybe I'm
mis-interpreting  something in the following :-)

While looking for the source of this 'Profiling timer expired' thing in the
recent snapshot-kernel I came across the following code fragment in
kern/kern_clock.c:

    if (timerisset(&pstats->p_timer[ITIMER_PROF].it_value) &&
        itimerdecr(&pstats->p_timer[ITIMER_PROF], tick) == 0)
                        psignal(p, SIGPROF);

This looks like the point in the kernel where a process get's - uhm - shot
down. First it is checked whether the process has set up a profiling timer
and then there is the check if the timer has expired. But there is another
way this statement can be interpreted: If the logical AND of the return
value of the called functions evaluates to FALSE, the condition fires, and I
don't think that this behaviour is intended. Wouldn't it be safer to put
some additional braces around the two conditions, i.e.

    if ( timerisset(&pstats->p_timer[ITIMER_PROF].it_value) &&
         (itimerdecr(&pstats->p_timer[ITIMER_PROF], tick) == 0) )
       ^^^               psignal(p, SIGPROF);
^^^

The second question is why this condition fires on rather random occasions.
If I'm persistent and repeatedly run a command that triggers a 'SIGPROF'
chances are that it will run at least once.

As said above, I'm not a kernel hacker and maybe I'm causing someone more
knowledgable than me to ROTFL :-)

Any input appreciated,
Marc