DragonFlyBSD

On Wednesday 07 April 2010 07:02:27 laurent laborde (via DragonFly issue
tracker) wrote:

New submission from laurent laborde <kerdezixe@gmail.com>:

step to reproduce the problem :

• Fresh install of 2.6.1
• cd /usr
• make pkgsrc-create
• cd /usr/pkgsrc
• bmake
• press ^c (ctrl-c) after a few seconds
• you get the shell prompt, but some process (look like "configure" stuff)
  keep running in the background and flood your terminal. doing a "killall
  bmake" (or killall -9 bmake) doesn't help.

I can confirm this is an isssue.

Petr

Hi,

Well, yes. A lot of bmake process will be spawned and you will have a
bad time to stop them all. What I use to do the to run a ton of
'killall -9 bmake' very fast until there are no processes left. Of
course this is just a rude workaround, but it gives you the chance to
avoid the reboot :P

Cheers,
Antonio Huete

2010/4/7 Petr Janda <elekktretterr@exemail.com.au>:

On Wednesday 07 April 2010 07:02:27 laurent laborde (via DragonFly issue
tracker) wrote:

New submission from laurent laborde <kerdezixe@gmail.com>:

step to reproduce the problem :

• Fresh install of 2.6.1
• cd /usr
• make pkgsrc-create
• cd /usr/pkgsrc
• bmake
• press ^c (ctrl-c) after a few seconds
• you get the shell prompt, but some process (look like "configure" stuff)
   keep running in the background and flood your terminal. doing a "killall
   bmake" (or killall -9 bmake) doesn't help.

I can confirm this is an isssue.

Petr

The main problem with bmake is that it temporarily sets a signal
handler to SIG_IGN before setting it to something else. This
means that when a ton of bmakes are running hitting ^C will often
be ignored by some of them. DragonFly is doing the right thing, it's
bmake which has to be fixed.

-Matt

Am 07.04.2010 09:37, schrieb Matthew Dillon:

The main problem with bmake is that it temporarily sets a signal
handler to SIG_IGN before setting it to something else. This
means that when a ton of bmakes are running hitting ^C will often
be ignored by some of them. DragonFly is doing the right thing, it's
bmake which has to be fixed.

As far as I remember, our make(1) has the same bug. It can be triggered
quite easily (at least here) by going to /usr/src, do 'make clean' and
trying to ^C it. I just tried it.

Sascha

On Wed, 7 Apr 2010 09:26:48 +0200
Antonio Huete Jimenez <ahuete.devel@gmail.com> wrote:

Hi,

Well, yes. A lot of bmake process will be spawned and you will have a
bad time to stop them all. What I use to do the to run a ton of
'killall -9 bmake' very fast until there are no processes left. Of
course this is just a rude workaround, but it gives you the chance to
avoid the reboot :P

while killall -9 bmake; do cat /dev/null; done
Should do the job and drop out when they're all gone.

: while killall 9 bmake; do cat /dev/null; done
:
: Should do the job and drop out when they're all gone.
:
:-
:Steve O'Hara-Smith | Directable Mirror Arrays

This is primarily due to a bug in bmake. bmake temporarily SIG_IGN's various signals before installing their signal handler so if a lot of bmakes are running and you hit ^C, sometimes some don't get killed.

-Matt

:As far as I remember, our make(1) has the same bug. It can be triggered
:quite easily (at least here) by going to /usr/src, do 'make clean' and
:trying to ^C it. I just tried it.
:
:Sascha

There might be another issue with signal races and fork(). The only two possible issues are programs ignoring ^C and a signal race in fork() (where the signal gets caught during the fork() but the child is then created and never gets the signal).

-Matt

Am 07.04.2010 18:29, schrieb Matthew Dillon:

There might be another issue with signal races and fork(). The only
two possible issues are programs ignoring ^C and a signal race in
fork() (where the signal gets caught during the fork() but the
child is then created and never gets the signal).

I've looked a bit at this with tuxillo and in our make's case it's -B
(compatMake == true) which exposes the buggy behavior.

compatMake is false when you use -j and true when you don't. As soon as
I run 'make -j 1 clean' it no longer fails.

Sascha