On Fri, 2020-07-24 at 17:59 +0200, Fabio Valentini wrote:
On Fri, Jul 24, 2020 at 5:48 PM Jeff Law <law(a)redhat.com>
wrote:
> On Fri, 2020-07-24 at 17:44 +0200, Fabio Valentini wrote:
> > On Fri, Jul 24, 2020 at 5:11 PM Jeff Law <law(a)redhat.com> wrote:
> > > > One error I've seen in libreoffice is a gcc / annobin segfault:
> > > >
> > > > [build CXX] vcl/unx/gtk3/gtk3gtkinst.cxx
> > > > *** WARNING *** there are active plugins, do not report this as a
bug
> > > > unless you can reproduce it without enabling any plugins.
> > > > Event | Plugins
> > > > PLUGIN_FINISH_UNIT | annobin: Generate final
annotations
> > > > PLUGIN_START_UNIT | annobin: Generate global
annotations
> > > > PLUGIN_ALL_PASSES_START | annobin: Generate per-function
annotations
> > > > PLUGIN_ALL_PASSES_END | annobin: Register per-function end
symbol
> > > > /builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:
In
> > > > destructor 'virtual DemoWin::RenderThread::~RenderThread()':
> > > >
/builddir/build/BUILD/libreoffice-6.4.5.2/vcl/workben/vcldemo.cxx:1733:18:
> > > > internal compiler error: Segmentation fault
> > > > 1733 | join();
> > > This sounds like a compiler bug. Can you try adding
> > > "%define _lto_cflags %{nil}"
> > >
> > > To the .spec file and see if that gets you over the hump? I've seen
one failure
> > > of this nature in my LTO testing and haven't gotten around to
producing a
> > > bugreport suitable for upstream (but the affected package has LTO disabled
to
> > > keep it from failing its builds). My tester reports that it's never
got a clean
> > > control build of libreoffice, so I've never dug into it for any LTO
specific
> > > failures.
> >
> > I added this %define _lto_cflags %{nil} to the top of the libreoffice
> > .spec file, and compiled it in mock locally.
> > And it spits out the same GCC crash error message without LTO.
> THanks for checking. That'll make things easier ;-)
>
> Add -save-temps to the compile line and also build with V=1 so you can get the
> full command line. Pass along the .ii file and that full command line and I'll
> take a peek at what's going on inside GCC.
>
> jeff
>
Looks like somebody already did that and attached the .ii file to the RHBZ.
https://bugzilla.redhat.com/show_bug.cgi?id=1859588 Unfortunately neither Marek nor
I can reproduce with the compilers we've tested.
Is it possible the OOM killer is killing the process? Is there anything in the
system logs that might be relevant?
Jeff