1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

[Randal L. Schwartz]

    SUBDIR perl
make[1]: `perl.mak' is up to date.
    GEN git-add--interactive
Writing perl.mak for Git
make[2]: *** [perl.mak] Error 1
make[1]: *** [instlibdir] Error 2
make: *** [git-add--interactive] Error 2

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: 1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

[Ævar Arnfjörð Bjarmason]

On Tue, Oct 5, 2010 at 20:48, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>    SUBDIR perl
> make[1]: `perl.mak' is up to date.
>    GEN git-add--interactive
> Writing perl.mak for Git
> make[2]: *** [perl.mak] Error 1
> make[1]: *** [instlibdir] Error 2
> make: *** [git-add--interactive] Error 2

1e63341 is a merge commit, and none of the merged things (in the
commit message) seem to have anything to do with the Perl makefile
process.

Can you run:

    make -j 1 V=1

And report what output you get?

Re: 1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

[Randal L. Schwartz]

>>>>> "Ævar" == Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Ævar> 1e63341 is a merge commit, and none of the merged things (in the
Ævar> commit message) seem to have anything to do with the Perl makefile
Ævar> process.

Ævar> Can you run:

Ævar>     make -j 1 V=1

Ævar> And report what output you get?

Oddly enough, just rerunning the make again *worked*.

That's scary.

And therefore also not bisectable. :(

I imagine there's some heisenbug in there, that we'll probably trip over
later.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: 1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

[Jeff King]

On Tue, Oct 05, 2010 at 02:13:53PM -0700, Randal L. Schwartz wrote:

> >>>>> "Ævar" == Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> Ævar> 1e63341 is a merge commit, and none of the merged things (in the
> Ævar> commit message) seem to have anything to do with the Perl makefile
> Ævar> process.
> 
> Ævar> Can you run:
> 
> Ævar>     make -j 1 V=1
> 
> Ævar> And report what output you get?
> 
> Oddly enough, just rerunning the make again *worked*.
> 
> That's scary.
> 
> And therefore also not bisectable. :(
> 
> I imagine there's some heisenbug in there, that we'll probably trip over
> later.

This has come up before, but nobody has managed to track it down. I did
some looking at it in the past, but this is all I could find:

  http://article.gmane.org/gmane.comp.version-control.git/117710

If my analysis there is right, we could probably protect against it with
something like:

diff --git a/Makefile b/Makefile
index 25f94b0..aaef528 100644
--- a/Makefile
+++ b/Makefile
@@ -1596,6 +1596,10 @@ ifndef NO_PYTHON
 endif
 	$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1) SHELL_PATH='$(SHELL_PATH_SQ)' PERL_PATH='$(PERL_PATH_SQ)'
 
+ifndef NO_PERL
+all:: perl/perl.mak
+endif
+
 please_set_SHELL_PATH_to_a_more_modern_shell:
 	@$$(:)
 

But of course it's hard to test.

-Peff

Re: 1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

[Sverre Rabbelier]

Heya,

On Tue, Oct 5, 2010 at 23:34, Jeff King <peff@peff.net> wrote:
> +ifndef NO_PERL
> +all:: perl/perl.mak
> +endif
> +

Regardless of whether that fixes the problem that looks like a sane
patch, so maybe we just should apply it?

-- 
Cheers,

Sverre Rabbelier

Re: 1e633418479926bc85ed21a4f91c845a3dd3ad66 breaks on OSX

[Jeff King]

On Wed, Oct 06, 2010 at 12:33:20AM +0200, Sverre Rabbelier wrote:

> On Tue, Oct 5, 2010 at 23:34, Jeff King <peff@peff.net> wrote:
> > +ifndef NO_PERL
> > +all:: perl/perl.mak
> > +endif
> > +
> 
> Regardless of whether that fixes the problem that looks like a sane
> patch, so maybe we just should apply it?

I'm not opposed, though the situation is confusing enough I'd like to
have somebody confirm that my previous analysis makes sense (otherwise,
this is just adding cruft to the Makefile :) ).

Sadly, I can't seem to replicate the original problem, even doing
something like:

  n=1
  while true; do
    make clean;
    if ! make -j4; then break; fi
    echo $n; n=$(($n+1))
  done

(and I tried several variations). It ran for 20 minutes without failing.
My suspicion is that there may be some particular state that triggers
the race condition, but I can't seem to figure it out.

-Peff