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

Debbugs page

M
M
Maxim Cournoyer wrote on 17 Jul 2017 06: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 02: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 04: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 05: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 05:37
control message for bug #27733
(address . control@debbugs.gnu.org)
87eft23vjc.fsf@gnu.org
tags 27733 notabug
close 27733
?
Your comment

This issue is archived.

To comment on this conversation send an email to 27733@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 27733
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch