Apparent race in buildworld (head/amd64, r322214 -> r322304)

[Bryan Drewery]

On 8/9/2017 12:35 PM, David Wolfskill wrote:
> On Wed, Aug 09, 2017 at 12:22:20PM -0700, Bryan Drewery wrote:
>>> 	/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
>> ... 
>>
>> This should fix it:
>> https://people.freebsd.org/~bdrewery/patches/gcc_s-install-race.diff
>>
>> The problem has consistently been, from your reports, that gcc_s is
>> being installed to WORLDTMP *while* something is trying to link to it.
> 
> Yeah, that doesn't seem like something that's likely to have
> deterministic results.
> 
>> ...
>>> --- lib/libc++__L ---
>>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
>>>
>>> --- lib/libgcc_s__L ---^M                                                     
>> ...
>>> --- all_subdir_secure/lib/libcrypto/engines/libsureware ---^M                 
>>> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M                        
>>
>>
>>
>> By default 'install' unlinks the file and then copies over the new file.
>>  Using PRECIOUSLIB we get the -S flag to install which is atomic in its
>> installation.
>>
>> Note the patch is not what I will commit. At Isilon we changed our
>> install to always use -S for library installation, but not to force schg
>> on.  I am considering making that change the default, to use -S for all
>> libraries.
> 
> From an (admittedly) naive perspective, it seems to me that enforcing
> "atomic installation" for file system objects that are to be used
> during the build (or install) makes more sense than firing and
> hoping for the best.  :-}
> 

It also fixes some runtime crashes while concurrently running
installworld to a live system.  One that we ran into a lot was an NSS
module being used for user lookup that another concurrent install would
use while the module was being overwritten.  It would see a bogus file
during the install.

>> -- 
>> Regards,
>> Bryan Drewery
>>
> 
> Thanks! :-)
> 
> Peace,
> david
> 


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170809/5f76280a/attachment.sig>