bugPSPP - Bugs: bug #60192, make -j4 routinely has issues

 
 

bug #60192: make -j4 routinely has issues

Submitted by:  Jeremy Lavergne <snc>
Submitted on:  Mon 08 Mar 2021 04:20:15 PM UTC
 
Category:  Compilation/Portability Severity:  5 - Average
Status:  Confirmed Assigned to:  None
Open/Closed:  Open Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sat 09 Apr 2022 04:55:37 PM UTC, comment #11: 

I don't think we can get rid of BUILT_SOURCES because there are so many:

BUILT_SOURCES = $(ALLOCA_H) $(BYTESWAP_H) gl/configmake.h gl/ctype.h \
        gl/malloc/dynarray.gl.h gl/malloc/dynarray-skeleton.gl.h \
        $(ERRNO_H) gl/fcntl.h $(FLOAT_H) $(FNMATCH_H) $(GETOPT_H) \
        $(GETOPT_CDEFS_H) gl/inttypes.h gl/langinfo.h $(LIMITS_H) \
        gl/locale.h gl/math.h gl/malloc/scratch_buffer.gl.h \
        gl/signal.h $(STDALIGN_H) $(STDARG_H) $(STDBOOL_H) $(STDDEF_H) \
        $(STDINT_H) gl/stdio.h gl/stdlib.h gl/string.h gl/strings.h \
        gl/sys/random.h gl/sys/select.h gl/sys/socket.h gl/sys/stat.h \
        gl/sys/time.h gl/sys/types.h gl/sys/uio.h gl/termios.h \
        gl/time.h $(LIBUNISTRING_UNICASE_H) \
        gl/unicase/special-casing-table.h gl/unicase/special-casing.h \
        $(LIBUNISTRING_UNICTYPE_H) $(LIBUNISTRING_UNIGBRK_H) \
        $(LIBUNISTRING_UNILBRK_H) $(LIBUNISTRING_UNINORM_H) \
        gl/unistd.h $(LIBUNISTRING_UNISTR_H) \
        $(LIBUNISTRING_UNITYPES_H) $(LIBUNISTRING_UNIWBRK_H) \
        $(LIBUNISTRING_UNIWIDTH_H) gl/wchar.h gl/wctype.h \
        $(light_binary_out) $(old_binary_out) $(detail_xml_out) \
        $(structure_xml_out) $(tlo_out) $(am__append_154)

Also, when I get rid of SUBDIRS I get an error from automake:

configure.ac: error: AM_GNU_GETTEXT used but SUBDIRS not defined

Ben Pfaff <blp>
Project Administrator
Sat 09 Apr 2022 04:47:28 PM UTC, comment #10: 

Removing the SUBDIRS variable results in replacing "all-recursive" with "all-am", so already better. But for us this only means that the po directory will not be build recursively. I had a look at the automake source here:

https://git.savannah.gnu.org/cgit/automake.git/tree/bin/automake.in

===SNIP===

    my @local_headers = ();
    push @local_headers, '$(BUILT_SOURCES)'
      if var ('BUILT_SOURCES');
    foreach my $spec (@config_headers)
      {
        my ($out, @ins) = split_config_file_spec ($spec);
        push @local_headers, basename ($out)
          if dirname ($out) eq $relative_dir;
      }

    if (@local_headers)
      {
        # We need to make sure config.h is built before we recurse.
        # We also want to make sure that built sources are built
        # before any ordinary 'all' targets are run.  We can't do this
        # by changing the order of dependencies to the "all" because
        # that breaks when using parallel makes.  Instead we handle
        # things explicitly.
        $output_all .= ("all: @local_headers"
                        . "\n\t"
                        . '$(MAKE) $(AM_MAKEFLAGS) '
                        . (var ('SUBDIRS') ? 'all-recursive' : 'all-am')
                        . "\n\n");
        depend ('.MAKE', 'all');
      }
    else
      {
        $output_all .= "all: " . (var ('SUBDIRS')
                                  ? 'all-recursive' : 'all-am') . "\n\n";
      }
}

which means that we must not have "local-headers". Getting rid of "config.h" and other "BUILT_SOURCES" will result in a non-recursive setup. Conceptually those "build sources" could be regular dependencies or am I wrong?

Friedrich Beckmann <beckmanf>
Project Member
Sat 09 Apr 2022 04:14:16 PM UTC, comment #9: 

I think you must be right.

It's unfortunate but I don't think there's a way around that. I tried, for example, setting SUBDIRS to the empty string (instead of to "po"), and it didn't make a difference.  If also getting rid of BUILT_SOURCES would make a difference, that's hopeless, because gnulib has a huge number of built sources.

Ben Pfaff <blp>
Project Administrator
Sat 09 Apr 2022 03:05:25 PM UTC, comment #8: 

I think the root cause for this problem is the recursive nature of the Makefile. The "all" target in the Makefile looks like this:

all: $(BUILT_SOURCES) config.h
        $(MAKE) $(AM_MAKEFLAGS) all-recursive

while the "html" target is not calling another make instance. Both targets "all-recursive" and "html" will in the end have the pspp executable as dependency but because they run in independent make instances, they do not know about each other. Therefore both start the build of the common dependency.

I made a small test Makefile.

# Testmakefile to show recursive make
allrec:
        $(MAKE) t1
all: t1 t2
t1: t3
        echo "Hallo t1"
        sleep 2
        echo "This is t1" >> t1
t2: t3
        echo "Start t2 - now sleep"
        sleep 1
        echo "This is t2" >> t2
t3:
        echo "Hallo t3"
        sleep 1
        echo "This is t3" >> t3
clean:
        rm t*

If you run "make -j4 allrec t2", then you see that t3 target is called twice. Calling "make -j4 all t2" will show the correct result, i.e. t3 target is only build once. Calling "make allrec t2" also works. My assumption is that this parallel build will result in some race conditions.

I did not manage to convince autotools to avoid the call of another make instance even for the hello world example. So I guess we have to live with this.

Friedrich Beckmann <beckmanf>
Project Member
Sat 09 Apr 2022 07:17:44 AM UTC, comment #7: 

I can't reproduce it on a 16 core Ubuntu 20.04 LTS machine. Strange.

Friedrich Beckmann <beckmanf>
Project Member
Fri 08 Apr 2022 03:47:14 PM UTC, comment #6: 

I've run into similar issues before when running "make" with multiple targets that depend on the pspp binary.  I've failed to solve it.  I'd welcome help.

Ben Pfaff <blp>
Project Administrator
Fri 08 Apr 2022 09:34:49 AM UTC, comment #5: 

After changing the debian/rules file according to the suggestions below, i.e.

make -jX all
make -jX html pdf

and making a debian 1.5.4-2 release, the build works - leaving some other problems not related to this topic.

Here is for example the difference for the amd64 architecture:

https://buildd.debian.org/status/logs.php?pkg=pspp&arch=amd64

1.5.4-2 (make -j4 all; make -j4 html pdf)  works
1.5.4-1 (make -j4 all html pdf) does not work

Friedrich Beckmann <beckmanf>
Project Member
Fri 08 Apr 2022 06:10:36 AM UTC, comment #4: 

Maybe this is the reason that version 1.5.4 on debian now fails on nearly all architectures except "hurd-i386" and "sh4"? The log shows

hurd-i386: make -j1 all html pdf
sh4: make -j1 all html pdf

all other architecture run with -jX with X > 1 ...

https://buildd.debian.org/status/package.php?p=pspp

Is this because html and pdf now have the pspp binary as dependency themself such that race conditions occur? I do not see this during my local builds for debian, probably because I build in a vmware vm on a macbook laptop and then inside a pbuilder. My laptop shows

machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz
machdep.cpu.core_count: 2
machdep.cpu.thread_count: 4

I also cannot reproduce this when building for MacOS on my macbook.

Friedrich Beckmann <beckmanf>
Project Member
Mon 15 Mar 2021 03:25:52 PM UTC, comment #3: 

I'm going to leave this open for the moment because it's worth trying to make this (that is, "make -j4 all html") work again, but I was not successful the last time I tried.

Ben Pfaff <blp>
Project Administrator
Mon 15 Mar 2021 03:21:03 PM UTC, comment #2: 

Yup, removing building the docs resolved the problem.

comment #1:

> I don't think this is fixable when you execute multiple targets in one "make".  Try "make -j4 all; make -j4 html".

Jeremy Lavergne <snc>
Mon 08 Mar 2021 04:29:17 PM UTC, comment #1: 

I don't think this is fixable when you execute multiple targets in one "make".  Try "make -j4 all; make -j4 html".

Ben Pfaff <blp>
Project Administrator
Mon 08 Mar 2021 04:20:15 PM UTC, original submission:  

For the past several weeks building off master has resulted in errors when using 4 parallel jobs however building without parallel is fine.

This week's errors introduce themselves around the generation of header files (prepending "DO NOT EDIT"), and it's not always the same header file.

From `make -j4 -w all html` on commit `37f29c`:

rm -f unilbrk.h-t unilbrk.h && \
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          cat ./unilbrk.in.h; \
        } > unilbrk.h-t && \
        mv -f unilbrk.h-t unilbrk.h
rm -f uninorm.h-t uninorm.h && \
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          cat ./uninorm.in.h; \
        } > uninorm.h-t && \
        mv -f uninorm.h-t uninorm.h
rm -f unistd.h-t unistd.h && \
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          sed -e 's|@''GUARD_PREFIX''@|GL|g' \

        } > unistd.h-t && \
        mv unistd.h-t unistd.h
make[2]: Entering directory `/opt/local/var/macports/build/_Users_aeetes_macports-ports_math_pspp-devel/pspp-devel/work/pspp-1.5.2-g37f29c/g
l'
rm -f unilbrk.h-t unilbrk.h && \
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          cat ./unilbrk.in.h; \
        } > unilbrk.h-t && \
        mv -f unilbrk.h-t unilbrk.h
rm -f uninorm.h-t uninorm.h && \
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          cat ./uninorm.in.h; \
        } > uninorm.h-t && \
        mv -f uninorm.h-t uninorm.h
mv: rename unilbrk.h-t to unilbrk.h: No such file or directory
rm -f unistr.h-t unistr.h && \
        { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          cat ./unistr.in.h; \
        } > unistr.h-t && \
        mv -f unistr.h-t unistr.h
make[1]: *** [unilbrk.h] Error 1
make[1]: *** Waiting for unfinished jobs....

Jeremy Lavergne <snc>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by beckmanf (Posted a comment)
  • -email is unavailable- added by blp (Posted a comment)
  • -email is unavailable- added by snc (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-04-08 beckmanf StatusNone => Confirmed
    2021-03-15 blp CategoryNone => Compilation/Portability

    Back to the top


    Powered by Savane 3.9