GCC compiler error when building LibreOffice 5.3.2.2

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 17 Jul 2017 15:03
(name . bug-guix)(address . bug-guix@gnu.org)
87bmojrzas.fsf@gmail.com
Hello,

While attempting to install LibreOffice 5.3.2.2 with the following
command:

./pre-inst-env guix package -i libreoffice -c 1 -M 1

GCC crashed with the following message:

Toggle snippet (37 lines)
[build CXX] sw/source/uibase/app/apphdl.cxx
[build CXX] sw/source/uibase/app/applab.cxx
[build CXX] sw/source/uibase/app/appopt.cxx
[build CXX] sw/source/uibase/app/docsh.cxx
[build CXX] sw/source/uibase/app/docsh2.cxx
[build CXX] sw/source/uibase/app/docshdrw.cxx
[build CXX] sw/source/uibase/app/docshini.cxx
[build CXX] sw/source/uibase/app/docst.cxx
[build CXX] sw/source/uibase/app/docstyle.cxx
In file included from /gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/algorithm:61:0,
from /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/include/com/sun/star/uno/Any.hxx:24
from /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/include/svl/poolitem.hxx:27,
from /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/include/svl/itemset.hxx:25,
from /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/include/svl/itemiter.hxx:23,
from /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/sw/source/uibase/app/docstyle.cxx:2
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h: In instantiation of ‘_BI2 std::_
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h:614:5: required from ‘_BI2 std:**, std::vector<SwRangeRedline*, std::allocator<SwRangeRedline*> > >; _BI2 = __gnu_cxx::__normal_iterator<SwRangeRedlin
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h:684:48: required from ‘_BI2 std*, std::allocator<SwRangeRedline*> > >; _BI2 = __gnu_cxx::__normal_iterator<SwRangeRedline**, std::vector<SwRangeRedlin
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algo.h:1846:8: required from ‘void std::___iterator<SwRangeRedline**, std::vector<SwRangeRedline*, std::allocator<SwRangeRedline*> > >; _Compare = __gnu_cxx::__o
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algo.h:2776:25: required from ‘void std::_normal_iterator<SwRangeRedline**, std::vector<SwRangeRedline*, std::allocator<SwRangeRedline*> > >; _Compare = __gnu_cx
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algo.h:4863:28: required from ‘void std::_terator<SwRangeRedline**, std::vector<SwRangeRedline*, std::allocator<SwRangeRedline*> > >; _Compare = __gnu_cxx::__ops
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algo.h:4932:36: required from ‘void std::seRedline*, std::allocator<SwRangeRedline*> > >; _Compare = CompareSwRedlineTable]’
/tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/include/o3tl/sorted_vector.hxx:186:25: required from ‘vFind = o3tl::find_partialorder_ptrequals]’
/tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/sw/inc/docary.hxx:362:60: required from here
/gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h:607:5: internal compiler error: S
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [/tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/solenv/gbuild/LinkTarget.mk:191: /tmp/guix-
make: *** [Makefile:265: build] Error 2
phase `build' failed after 35006.0 seconds
builder for `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv' failed with exit code 1
guix package: error: build failed: build of `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv' faile

The reason I'm limiting the number of build processes and cores used to
1 (with the -c and -M flags of `guix build`) is because one dependency
of LibreOffice, vigra, was taking up to 2 GiB of memory per process when
compiling and causing my 4 GiB system to trash.

Maxim
L
L
Ludovic Courtès wrote on 18 Jul 2017 11:58
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 27733@debbugs.gnu.org)
87d18y2hjp.fsf@gnu.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (18 lines)
> /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/sw/inc/docary.hxx:362:60: required from here
> /gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h:607:5: internal compiler error: S
> }
> ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[1]: *** [/tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/solenv/gbuild/LinkTarget.mk:191: /tmp/guix-
> make: *** [Makefile:265: build] Error 2
> phase `build' failed after 35006.0 seconds
> builder for `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv' failed with exit code 1
> guix package: error: build failed: build of `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv' faile
>
> The reason I'm limiting the number of build processes and cores used to
> 1 (with the -c and -M flags of `guix build`) is because one dependency
> of LibreOffice, vigra, was taking up to 2 GiB of memory per process when
> compiling and causing my 4 GiB system to trash.

Are you suggesting that the build error above can also be an
out-of-memory issue? Did “dmesg” show anything mentioning OOM?

These C++ code bases (WebKit, LibreOffice, etc.) usually require a lot
of RAM to build, so it could be that your machine simply doesn’t have
enough RAM.

AFAICS it builds fine on Hydra:


but not in 32 bit:


Ludo’.
M
M
Maxim Cournoyer wrote on 18 Jul 2017 13:51
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 27733@debbugs.gnu.org)
877ez6rmi3.fsf@gmail.com
Hi Ludovic!

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (30 lines)
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/sw/inc/docary.hxx:362:60: required from here
>> /gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h:607:5:
>> internal compiler error: S
>> }
>> ^
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <http://gcc.gnu.org/bugs.html> for instructions.
>> make[1]: ***
>> [/tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/solenv/gbuild/LinkTarget.mk:191:
>> /tmp/guix-
>> make: *** [Makefile:265: build] Error 2
>> phase `build' failed after 35006.0 seconds
>> builder for `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv' failed with exit code 1
>> guix package: error: build failed: build of
>> `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv'
>> faile
>>
>> The reason I'm limiting the number of build processes and cores used to
>> 1 (with the -c and -M flags of `guix build`) is because one dependency
>> of LibreOffice, vigra, was taking up to 2 GiB of memory per process when
>> compiling and causing my 4 GiB system to trash.
>
> Are you suggesting that the build error above can also be an
> out-of-memory issue? Did “dmesg” show anything mentioning OOM?

That would have been plausible, but at the time it crashed I had
verified /var/log/messages and didn't see OOM problems, although there
was messages such as:

Jul 16 17:55:29 localhost vmunix: [ 1222.229040] perf: interrupt took too long (6239 > 6227), lowering kernel.perf_event_max_sample_rate to 32000
Jul 16 18:00:16 localhost vmunix: [ 1509.558118] perf: interrupt took
too long (7800 > 7798), lowering kernel.perf_event_max_sample_rate to
25500

which I attributed to the high system load.

Toggle quote (4 lines)
> These C++ code bases (WebKit, LibreOffice, etc.) usually require a lot
> of RAM to build, so it could be that your machine simply doesn’t have
> enough RAM.

Further removing the possibility that it was an out-of-memory issue is
that last night I could successfully build libreoffice after I took out
the -c 1 and -M 1 flags. This should have made the memory requirements
even higher but it made it through the compilation, and only failed to
install due to unrelated issues in my profile:

Toggle snippet (14 lines)
starting phase `reset-gzip-timestamps'
phase `reset-gzip-timestamps' succeeded after 0.4 seconds
starting phase `compress-documentation'
phase `compress-documentation' succeeded after 0.0 seconds
The following package will be installed:
libreoffice 5.3.2.2 /gnu/store/qkwdx123vqrwglkrqzqhk1nxknxzjf7w-libreoffice-5.3.2.2

guix package: error: profile contains conflicting entries for gtk+:out
guix package: error: first entry: gtk+@2.24.31:out /gnu/store/cakcwzawnhp9iyn5c0jcyh4lnlh5ayym-gtk+-2.24.31
guix package: error: ... propagated from murrine@0.98.2
guix package: error: second entry: gtk+@3.22.15:out /gnu/store/4jgdaix3hlar9wh2jfpf99yblmzpawfr-gtk+-3.22.15
guix package: error: ... propagated from python-ipython@5.2.2

So it's possible that the problem is only exhibited when building
Libreoffice with a single core although that seems unlikely. I will
retry the build with the -c 1 and -M 1 flags and see if I can reproduce
the problem.

Thanks!

Maxim
L
L
Ludovic Courtès wrote on 18 Jul 2017 14:34
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 27733@debbugs.gnu.org)
87vampylcw.fsf@gnu.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (43 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> /tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/sw/inc/docary.hxx:362:60: required from here
>>> /gnu/store/4iw4r2majarqlm19adaikqw126jxqf2p-gcc-5.4.0/include/c++/bits/stl_algobase.h:607:5:
>>> internal compiler error: S
>>> }
>>> ^
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>> make[1]: ***
>>> [/tmp/guix-build-libreoffice-5.3.2.2.drv-0/libreoffice-5.3.2.2/solenv/gbuild/LinkTarget.mk:191:
>>> /tmp/guix-
>>> make: *** [Makefile:265: build] Error 2
>>> phase `build' failed after 35006.0 seconds
>>> builder for `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv' failed with exit code 1
>>> guix package: error: build failed: build of
>>> `/gnu/store/mrq8p9v19fvl86igbhfkah0saj5n0awn-libreoffice-5.3.2.2.drv'
>>> faile
>>>
>>> The reason I'm limiting the number of build processes and cores used to
>>> 1 (with the -c and -M flags of `guix build`) is because one dependency
>>> of LibreOffice, vigra, was taking up to 2 GiB of memory per process when
>>> compiling and causing my 4 GiB system to trash.
>>
>> Are you suggesting that the build error above can also be an
>> out-of-memory issue? Did “dmesg” show anything mentioning OOM?
>
> That would have been plausible, but at the time it crashed I had
> verified /var/log/messages and didn't see OOM problems, although there
> was messages such as:
>
> Jul 16 17:55:29 localhost vmunix: [ 1222.229040] perf: interrupt took too long (6239 > 6227), lowering kernel.perf_event_max_sample_rate to 32000
> Jul 16 18:00:16 localhost vmunix: [ 1509.558118] perf: interrupt took
> too long (7800 > 7798), lowering kernel.perf_event_max_sample_rate to
> 25500
>
> which I attributed to the high system load.

OK.

Toggle quote (10 lines)
>> These C++ code bases (WebKit, LibreOffice, etc.) usually require a lot
>> of RAM to build, so it could be that your machine simply doesn’t have
>> enough RAM.
>
> Further removing the possibility that it was an out-of-memory issue is
> that last night I could successfully build libreoffice after I took out
> the -c 1 and -M 1 flags. This should have made the memory requirements
> even higher but it made it through the compilation, and only failed to
> install due to unrelated issues in my profile:

OK, weird.

Toggle quote (13 lines)
> starting phase `reset-gzip-timestamps'
> phase `reset-gzip-timestamps' succeeded after 0.4 seconds
> starting phase `compress-documentation'
> phase `compress-documentation' succeeded after 0.0 seconds
> The following package will be installed:
> libreoffice 5.3.2.2 /gnu/store/qkwdx123vqrwglkrqzqhk1nxknxzjf7w-libreoffice-5.3.2.2
>
> guix package: error: profile contains conflicting entries for gtk+:out
> guix package: error: first entry: gtk+@2.24.31:out /gnu/store/cakcwzawnhp9iyn5c0jcyh4lnlh5ayym-gtk+-2.24.31
> guix package: error: ... propagated from murrine@0.98.2
> guix package: error: second entry: gtk+@3.22.15:out /gnu/store/4jgdaix3hlar9wh2jfpf99yblmzpawfr-gtk+-3.22.15
> guix package: error: ... propagated from python-ipython@5.2.2

There are conflicting GTK+ versions being pulled here, hence the error.
If you think this case should be handled gracefully, please send a
message to bug-guix or guix-devel.

Toggle quote (5 lines)
> So it's possible that the problem is only exhibited when building
> Libreoffice with a single core although that seems unlikely. I will
> retry the build with the -c 1 and -M 1 flags and see if I can reproduce
> the problem.

Super weird!

Case closed?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 27 Jul 2017 14:37
control message for bug #27733
(address . control@debbugs.gnu.org)
87eft23vjc.fsf@gnu.org
tags 27733 notabug
close 27733
?