Re: A quick note about devel/afl++
Taylor R Campbell <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
> Date: Tue, 4 Aug 2026 22:06:57 +0000 (UTC) > From: John Klos <[email protected]> > > I remember there were issues with rust ignoring MAKE_JOBS in the past, but > that was on systems with multiple cores where rust used all the cores no > matter what. But where would afl++ get the idea that more than one job > simultaneously make sense? A cursory glance at the GNUmakefile shows: all: test_x86 test_shm test_python ready $(PROGS) llvm ... llvm: -$(MAKE) -j$(nproc) -f GNUmakefile.llvm I don't see nproc defined anywhere, so this will likely actually pass the plain argument `-j', which for GNU make means that it turns into a forkbomb, forking all the jobs that are ready without limit: -j [jobs], --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously. We should just patch this out; it is obviously wrong, and there is no reason for any ordinary makefile to do anything with -j itself.