[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #24, bug #49014 (project make): Thank you for looking into this and showing the committed change. I'll update our port to include this. ___ Reply to this item at:

[bug #49014] Zombies in parallel builds with pselect code

Update of bug #49014 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #23: I'm re-closing this :). The problem Kurt reports is a duplicate of bug #51400. It was fixed with

[bug #49014] Zombies in parallel builds with pselect code

Update of bug #49014 (project make): Open/Closed: Closed => Open ___ Follow-up Comment #22: I'll reopen this so I don't lose track of it. For the next release I wanted to completely rewrite

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #21, bug #49014 (project make): Thank you for the replies. Yes, the referenced commit (b552b0525198) was tried: https://github.com/openbsd/ports/commit/29ba9c2b7a4577f5aa1d85b6c9bf4696423886d8#diff-b2f76d26babda853136a6c3517055ebb but the pselect/zombie issue continued to show

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #20, bug #49014 (project make): Surely Kurt was running with that? Mind, he didn't say. I haven't seen my Linux problem in the 2+ years since applying b552b0525198. ___ Reply to this item at:

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #19, bug #49014 (project make): Please check the referenced commit. We've been running with it for over a year in pkgsrc now and the problems disappeared. ___ Reply to this item at:

[bug #49014] Zombies in parallel builds with pselect code

Additional Item Attachment, bug #49014 (project make): File name: gmake.pselect.diff Size:2 KB ___ Reply to this item at:

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #18, bug #49014 (project make): We continue to see gmake 4.2.1 get stuck with zombie's on OpenBSD with pselect(2). [comment #4 comment #4:] > I took a look through the code. I could to do a more comprehensive review but at first glance it looks like everything is OK: if PSELECT

[bug #49014] Zombies in parallel builds with pselect code

Update of bug #49014 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #17: I'm going to close th

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #16, bug #49014 (project make): I have built several large software suites (including KDE Frameworks and Plasma Workspaces) since applying this patch, and I have not seen the zombie problem recur. ___ Reply to this item at

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #15, bug #49014 (project make): I've been running with the git head as of your 2017-06-04 request. The problem hasn't recurred for me. I don't think that means as much as it would have a few months ago because I've had less cause to run my "pgid=$(find-pid-of-root-of-big-recurs

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #14, bug #49014 (project make): Any updates on this? Have you seen the pselect() zombie issue re-appear after applying the patch? Thanks for testing! ___ Reply to this item at: _

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #13, bug #49014 (project make): I've applied b552b0525198 to Make 4.2.1 on my Gentoo system (and have re-enabled HAVE_PSELECT). I will report back if I experience another deadlock. Thanks for the (probable) fix! ___ Reply

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #12, bug #49014 (project make): A fix for bug #51159 has been pushed to the Git repository. I have a strong suspicion that this is the same problem we're seeing here and that fix will also fix this issue. Knowing the problem I thought I might be able to conjure a scenario to fo

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #11, bug #49014 (project make): SIGCHLD doesn't always unstick the make process, though. It worked for me when I had a make with two zombie children, but it didn't work on another make that had only one zombie child. I think I'll try comment #0's suggestion of overriding the HAV

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #10, bug #49014 (project make): Matt's work around worked for my latest recurrence. I wonder if it gives us a clue as to the cause? I hadn't thought to try it and it's helpful not to have to kill the build, so thanks. ___

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #9, bug #49014 (project make): This issue also affects Make 4.2.1 on Linux 4.11.0-gentoo. I had a parallel build of Firefox stall in a make process with two unreaped children. Manually sending a SIGCHLD to the zombies' parent (make) process got everything moving again. _

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #8, bug #49014 (project make): > Also I suppose Linux 3.2 is pretty old at this point I'm now on: Linux swiftboat 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 GNU/Linux ... and still seeing the same behavior as I reported in comment #3, several times now. That t

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #7, bug #49014 (project make): It's a red herring. FreeBSD has been providing a system call since at least version 8.1 and 9.0. A correct userland implementation can be done on top of other primitives like ppoll or kqueue, but that's not relevant here. The common element for all

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #6, bug #49014 (project make): It can't be implemented in userland. What pselect() does is unblock the signal, call select, then have the signal blocked again on return. The point of using pselect() is that the signal unblock/block must be atomic with the select() system call.

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #5, bug #49014 (project make): (1) I'm pretty sure that pselect can be implemented correctly in userland. (2) It doesn't matter as the original bug report was from NetBSD, where pselect is a system call. ___ Reply to this

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #4, bug #49014 (project make): I took a look through the code. I could to do a more comprehensive review but at first glance it looks like everything is OK: if PSELECT is enabled then we block SIGCHLD right at the start of the make process and we never unblock it except as a par

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #3, bug #49014 (project make): Happened to me again. All the zombies were preceded in the process tree by a make blocked on the read of job_fds[0] in the HAVE_PSELECT jobserver_acquire. I had, once again, sent the whole process group SIGSTOP and SIGCONT at some point.

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #2, bug #49014 (project make): Without pselect, I semi-reliable get errors like: gmake[3]: *** duping jobs pipe: Bad file descriptor. Stop. variants with ENOENT etc exists. According to https://secure.freshbsd.org/commit/freebsd-ports/r421562 this happens on FreeBSD with pse

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #1, bug #49014 (project make): I've had a couple of hung makes in the last couple of months where I've noticed a prominent number of zombies. I see my from-git make from 2016-06-11, reporting itself as 4.2.1, has HAVE_PSELECT=1 in config.status and imports that symbol from glibc

[bug #49014] Zombies in parallel builds with pselect code

URL: Summary: Zombies in parallel builds with pselect code Project: make Submitted by: joerg Submitted on: Tue 06 Sep 2016 12:38:41 PM GMT Severity: 3 - Normal Item Group