New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Race condition installing modules to lib in parallel builds #11032
Comments
From @tonycozCreated by @tonycozRarely, when performing a parallel build of perl there is a race In smoke logs this is seen as: File/Path.pm did not return a true value at ../../lib/AutoSplit.pm line 6. File/Path.pm did not return a true value at ../../lib/AutoSplit.pm line 6. ExtUtils/Install.pm did not return a true value. File/Spec.pm did not return a true value at ../../lib/File/Path.pm line 8. I ran a loop: while git clean -dxf && ./Configure -des -Dusedevel && make -j6 ; do true ; done On the 490th run: make[1]: Entering directory `/home/tony/dev/perl/git/perl/cpan/ExtUtils-MakeMake Creating Makefile.PL in ext/FileCache for FileCache Running Makefile.PL in ext/FileCache ExtUtils::Install::pm_to_blib reports the copy after performing the To test this, I modified ExtUtils/Install.pm: --- a/dist/ExtUtils-Install/lib/ExtUtils/Install.pm After 209 builds I get: +cp lib/File/Spec/Epoc.pm ../../lib/File/Spec/Epoc.pm As a further test I applied the following change locally: --- a/dist/ExtUtils-Install/lib/ExtUtils/Install.pm I ran my build loop again, and killed it after 2043 successful builds. I don't expect the change above is safe for blead: - the extra . in filename may be a problem for some systems, or the - ExtUtils::Install::_copy() is also used for installion to the final - some (non-CORE) modules may have filenames where the .work cause a For a real solution: a) some mechanism to make a non-conflicting filename b) some mechanism to retain ownership and permissions on the target file or c) perhaps use copy and rename only for building the perl core or d) ignore the problem, it only occurs rarely Perl Info
|
From @nwc10On Thu, Jan 13, 2011 at 01:22:40AM -0800, Tony Cook wrote:
I think that actually the correct solution is e) Patch ExtUtils::MakeMaker not to add ../../lib to miniperl's @INC when [given that all the relevant modules are now added to @INC by make_ext.pl because I think that the race condition is that ../../lib is first in @INC, But I'm not sure what the current state of patching ExtUtils::MakeMaker is. Nicholas Clark |
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Mon, Jan 17, 2011 at 10:49:43AM +0000, Nicholas Clark wrote:
Isn't this bug fixed by this change? (if so, my fault for not closing it) commit 5e4c4c9 Use a buildcustomize.pl to set @INC in miniperl when building extensions. Nicholas Clark |
From @tonycozOn Tue Apr 08 03:09:34 2014, nicholas wrote:
Yes, I think so. I knew about the commit (or at least the changed in behaviour) when I last looked at this ticket and it didn't occur to me either. Thanks, closing. Tony |
@tonycoz - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#82194 (status was 'resolved')
Searchable as RT82194$
The text was updated successfully, but these errors were encountered: