On Mon, Sep 25, 2000 at 03:02:05PM -0700, Linus Torvalds wrote:
> sigdelset(&list->signal, sig);
I just tested this using my perl-5.005-threads program... no change from
my last email (only 1023 threads created, program fails to respond to
ctrl-c when more than 1023 threads are attempted).
On Mon, Sep 25, 2000 at 10:33:06AM +0200, Ingo Molnar wrote:
> On Mon, 25 Sep 2000, Ted Deppner wrote:
>
> > I ask because on my perl-threads test case, I can't create more than 1023
> > threads, but I get a kernel crash when I've _attempted_ to create more
> > than 1023 and hit ctrl-c.
>
> coul
Duh. This was a really stupid bug.
In kernel/signal.c, collect_signal(), for the case where we don't find a
siginfo block, we need to clear the signal set.
In short, add the line
sigdelset(&list->signal, sig);
just before the first "return 1" in collect_signal(), and all should be
wel
btw., maybe it's init that gets those 2000 signals, not bash?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
indeed, after changing max_queued_signals to 4096, i cannot crash the
kernel anymore with 2000 threads.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Mon, 25 Sep 2000, Mark Hahn wrote:
> > The problem is large numbers of threads in 2.4.0-test8 can result in a
> > hard crash of the entire kernel. This can be done as a non-root user.
>
> this appears to be reproducable (128M duron, haven't tried intel UP/SMP):
i've done some experimentati
> The problem is large numbers of threads in 2.4.0-test8 can result in a
> hard crash of the entire kernel. This can be done as a non-root user.
this appears to be reproducable (128M duron, haven't tried intel UP/SMP):
// code derived from a clone demo in lmbench.
#include
#include
#include
7 matches
Mail list logo