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

 
 

bug #60192: make -j4 routinely has issues

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

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 25 Jun 2023 08:13:29 PM UTC, comment #15: 

So if we're not going to fix this one, then I'll close it.

John Darrington <jmd>
Group administrator
Sun 25 Jun 2023 07:55:39 PM UTC, comment #14: 

I don't think we can practically fix making multiple targets like "all html" work well in parallel.

If you just do a single target, -j128 works fine for me, repeatably, with my 128-thread CPU.

Ben Pfaff <blp>
Group administrator
Sun 25 Jun 2023 07:11:02 PM UTC, comment #13: 

Just tried `make -j10 all html`, still results in a build failure. That said, I'm usually building the targets separately to avoid the issue.


mv: rename src/libpspp/.deps/liblibpspp_la-sparse-xarray.Tpo to src/libpspp/.deps/liblibpspp_la-sparse-xarray.Plo: No such file or directory
make[1]: * [src/libpspp/liblibpspp_la-sparse-xarray.lo] Error 1


comment #12:

> As of commit 5dbc6859f8327ed71883c4535bae8d69f3cb0006 this works fine for me.
>
> Does anyone else still see this problem?

Jeremy Lavergne <snc>
Sun 25 Jun 2023 08:51:00 AM UTC, comment #12: 

As of commit 5dbc6859f8327ed71883c4535bae8d69f3cb0006 this works fine for me.

Does anyone else still see this problem?

John Darrington <jmd>
Group administrator
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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 jmd (Posted a comment)
  • -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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-06-25 jmd StatusConfirmed Wont Fix
        Open/ClosedOpen Closed
    2022-04-08 beckmanf StatusNone Confirmed
    2021-03-15 blp CategoryNone Compilation/Portability

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code