Hi Sebastian,
> > In all the successful loops the lines in the trace look like the lines in the successful
> (2nd) example below.
> > In the error case there is an additional sched_waking and sched_wakeup in the
> trace.
> > Also there is always "prev_state=S" within the forked process.
> > In the error case, there is "prev_state=T|K".
>
> That T|K is probably some kind of debug state the program remains until the
> debugger puts it back on track. I think the interesting part ist figure out what decided
> to send this signal or put the program into stop-state. Usually a breakpoint, invalid
> opcode, … causes this kind of action but my understanding is that you use none of
> those.
Perhaps I was not precise enough in my previous mail.
The effect that I described in there was not a SIGSTOP but a hanging thread.
I had to press CTRL-C to interrupt the execution and to enter the gdb prompt.
This hanging occurs in 10-20% of the runs.
Also here, this hang always occurs when one of the threads does a kind of "clone".
And this effect only appears it the kernel is configured for "full preemptible".
So there are two effects I have noticed:
- The strange SIGSTOP where I cannot provide a simple test executable
- The strange issue with the hanging thread (please use the example from my previous mail)
In both issues, a "clone" is executed in one of the threads.
Regards
Mathias
��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
