717947 - 'make clean' can go into infinite recursion

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Gervase Markham [:gerv]]

I just did a "make clean" on a comm-central tree, and got the following recurring output (it got up to 7000+ nested make processes before I broke out):

make[707]: Entering directory `/usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config'
rm -f .md  .bak core     Templates.DB ../dist/stl_wrappers/sentinel ../config/final-link-comps ../config/final-link-libs ../config/final-link-comp-names buildid /usr/src/comm-central/mozilla/config/*.pyc *.pyc nsinstall  elf-dynstr-gc   LOGS TAGS a.out     host_nsinstall.o host_pathsub.o host_nsinstall.o host_pathsub.o    so_locations _gen _stubs               
rm -f -r .deps _java system_wrappers stl_wrappers /no-such-file
cd /usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config/mkdepend; make clean
cd: 1: can't cd to /usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config/mkdepend
make[708]: Entering directory `/usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config'
rm -f .md  .bak core     Templates.DB ../dist/stl_wrappers/sentinel ../config/final-link-comps ../config/final-link-libs ../config/final-link-comp-names buildid /usr/src/comm-central/mozilla/config/*.pyc *.pyc nsinstall  elf-dynstr-gc   LOGS TAGS a.out     host_nsinstall.o host_pathsub.o host_nsinstall.o host_pathsub.o    so_locations _gen _stubs               
rm -f -r .deps _java system_wrappers stl_wrappers /no-such-file
cd /usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config/mkdepend; make clean
cd: 1: can't cd to /usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config/mkdepend
make[709]: Entering directory `/usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config'
...
(and so on for 7000 instances)

I don't know why it couldn't cd to the directory /usr/src/obj-i686-pc-linux-gnu-thunderbird/mozilla/config/mkdepend. And I'm afraid I nuked my objdir and rebuilt, so I can't look. I assume the dir wasn't there, but I can't be certain. Still, perhaps this bug report is useful. Shouldn't we be checking the "cd" succeeds?

Gerv

Comment 1

[[e-mail]]

mozilla/config/Makefile.in is actually a core makefile, so changing component.

Comment 2

[Ian]

I got a similar error when trying to build trunk firefox with "mk_add_options MOZ_PGO=1".

With pgo off, firefox builds fine except not pgo obviously.

With pgo on, I get the error.  Started about a week ago as far as I remember, I just assumed pgo broke again and turned it off and rebuilt.

Comment 3

[Joey Armstrong [:joey]]

Partially clean { or failed while building } sandboxes are prone to the problem.
An existence check prior to make clean may help prevent the problem.

If built, remove ${obj}/config/mkdepend before "make clean" and make will begin looping.


#!/bin/bash

obj=obj-x86_64-unknown-linux-gnu

gmake -C ${obj}/config COMPILER_DEPEND=
/bin/ls -ld obj-x86_64-unknown-linux-gnu/config/mkdepend
/bin/rm -fr ${obj}/config/mkdepend

gmake -f client.mk clean


cd /local/mozilla/bugs/mc/obj-x86_64-unknown-linux-gnu/config/mkdepend; gmake clean
cd: 1: can't cd to /local/mozilla/bugs/mc/obj-x86_64-unknown-linux-gnu/config/mkdepend
gmake[3]: Entering directory `/local/mozilla/bugs/mc/obj-x86_64-unknown-linux-gnu/config'
rm -f .md  .bak core     Templates.DB ../dist/stl_wrappers/sentinel ../config/final-link-comps ../config/final-link-libs ../config/final-link-comp-names buildid /local/mozilla/bugs/mc/config/*.pyc *.pyc nsinstall    LOGS TAGS a.out     host_nsinstall.o host_pathsub.o host_nsinstall.o host_pathsub.o    so_locations _gen _stubs               
rm -f -r _java system_wrappers stl_wrappers /no-such-file

Comment 4

[Joey Armstrong [:joey]]

Attachment: Attempt make clean on MKDEPEND_DIR only when it exists

Rewrote make clean line for MKDEPEND_DIR to only attempt recursive clean when the directory exists.  Otherwise short-circuit the call, succeed and keep going.

Comment 5

[John Schoenick [:johns]]

This was happening 100% of the time to me on linux with 'make clean', breaking PGO builds among other things. It seems to happen even on fully-built builds. `mkdepend` is never built/used (I couldn't quite follow the logic through the makefiles, but I believe it's defaulting to compiler-dependency generation). However, MKDEPEND_DIR is set, so it tries to clean it.

A quick hack to avoid having an extra patch on your tree is to put this in your build script:

> # Work around bug 717947
> (
>   cd "$objdir"
>   for x in {js/src/,}config; do
>     $MAKE -C $x DIRS+=mkdepend mkdepend/Makefile
>   done
> )

Thanks for looking into this Joey

Comment 6

[(not currently active) Ted Mielczarek]

I actually filed a bug on removing all the mkdepend stuff, bug 740854

Comment 7

[Joey Armstrong [:joey]]

(In reply to Ted Mielczarek [:ted] from comment #6)
> I actually filed a bug on removing all the mkdepend stuff, bug 740854

Would it be worth applying the patch to lessen pain threshold in the interim ?  I don't mind either way -- if mkdepend will be going away soon this big can be closed.

Comment 8

[Joey Armstrong [:joey]]

(In reply to John Schoenick [:johns] from comment #5)
> This was happening 100% of the time to me on linux with 'make clean',
> breaking PGO builds among other things. It seems to happen even on
> fully-built builds. `mkdepend` is never built/used (I couldn't quite follow
> the logic through the makefiles, but I believe it's defaulting to
> compiler-dependency generation). However, MKDEPEND_DIR is set, so it tries
> to clean it.
> 
> A quick hack to avoid having an extra patch on your tree is to put this in
> your build script:
> 
> > # Work around bug 717947
> > (
> >   cd "$objdir"
> >   for x in {js/src/,}config; do
> >     $MAKE -C $x DIRS+=mkdepend mkdepend/Makefile
> >   done
> > )
> 
> Thanks for looking into this Joey

Thanks for the local edit John

Comment 9

[(not currently active) Ted Mielczarek]

This doesn't need to be WONTFIX, it's a real bug. Fixing bug 740854 would be preferable to putting in some specific workaround here. I don't imagine it's a large task, just some cleanup.