Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 May 2020 19:33:24 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores
Message-ID:  <bug-246630-227-m88WoaNtrQ@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-246630-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-246630-227@https.bugs.freebsd.org/bugzilla/>

index | next in thread | previous in thread | raw e-mail

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630

Dimitry Andric <dim@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open

--- Comment #18 from Dimitry Andric <dim@FreeBSD.org> ---
So after quite a bit of head scratching, I found that the problem appears to be
caused by upstream commit
https://github.com/llvm/llvm-project/commit/b4a99a061f517e60985667e39519f60186cbb469:

commit b4a99a061f517e60985667e39519f60186cbb469
Author: Alexandre Ganea <alexandre.ganea@ubisoft.com>
Date:   Mon Jan 13 10:40:04 2020 -0500

    [Clang][Driver] Re-use the calling process instead of creating a new
process for the cc1 invocation

    With this patch, the clang tool will now call the -cc1 invocation directly
inside the same process. Previously, the -cc1 invocation was creating, and
waiting for, a new process.
    This patch therefore reduces the number of created processes during a
build, thus it reduces build times on platforms where process creation can be
costly (Windows) and/or impacted by a antivirus.
    It also makes debugging a bit easier, as there's no need to attach to the
secondary -cc1 process anymore, breakpoints will be hit inside the same
process.

    Crashes or signaling inside the -cc1 invocation will have the same
side-effect as before, and will be reported through the same means.

    This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1
cmake flag, which defaults to OFF. Setting it to ON will revert to the previous
behavior, where any -cc1 invocation will create/fork a secondary process.
    At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment
variable. Setting it and will override the compile-time setting. A value of 0
calls -cc1 inside the calling process; a value of 1 will create a secondary
process, as before.

    Differential Revision: https://reviews.llvm.org/D69825

For some reason, not spawning a second process for the cc1 stage has this
particular influence on the end result, and *only* for the printf.c file!

I'm still digging further into this rabbit hole, but for now a good workaround
is to set the environment variable CLANG_SPAWN_CC1=1. This forces the clang
driver to fork and exec a new instance for the cc1 stage, and clears up the
problem completely for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.

help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246630-227-m88WoaNtrQ>