GNU bug report logs - #31708
'gcc-strmov-store-file-names.patch' causes GCC segfaults

Previous Next

Full log

Message #19 received at 31708 <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31708 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Fri, 8 Jun 2018 12:04:03 +0200

[Message part 1 (text/plain, inline)]

2018-06-05 3:00 GMT+02:00 Mark H Weaver <mhw <at> netris.org>:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
> > On current ‘core-updates’, we have:
> >
> > $ readlink -f $(type -P gcc)
> > /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
> > ludo <at> ribbon /home/ludo/src/guix/+core-updates$ cat strmov-ice.c
> > #define _GNU_SOURCE
> > #include <string.h>
> >
> > void foo (char *x)
> > {
> >   static const char buf[12];
> >   memcpy (x, buf, 12);
> > }
> > $ gcc -dH -O2 -Wall -c strmov-ice.c
> > strmov-ice.c: In function ‘foo’:
> > strmov-ice.c:7:3: internal compiler error: Segmentation fault
> >    memcpy (x, buf, 12);
> >    ^
> > gcc: internal compiler error: Aborted (program cc1)
>
> [...]
>
> > This is because DECL_INITIAL returns NULL_TREE for ‘buf’, but
> > ‘store_reference_p’ doesn’t check whether we got NULL_TREE.
> >
> > The fix is very simple (adding a NULL_TREE check), but in the meantime
> > we need to work around it.
> >
> > A simple workaround is to pass an initializer to the static const array:
> >
> > $ cat strmov-ice.c
> > #define _GNU_SOURCE
> > #include <string.h>
> >
> > void foo (char *x)
> > {
> >   static const char buf[12] = { 0, };
> >   memcpy (x, buf, 12);
> > }
> > $ gcc -dH -O2 -Wall -c strmov-ice.c
> > $ echo $?
> > 0
> >
> > The meaning of the program is unchanged but the bug is not triggered.
>
> Thanks for tracking this down.  This explains why I've been seeing an
> unusually large number of internal compiler errors in this core-updates
> cycle.  It was a bit surprising since we used the same compiler in the
> previous cycle, so I was wondering what might be causing it.
>
> At the moment, the most pressing failure caused by this bug is 'doxygen'
> on armhf, which causes GCC to crash deterministically in the same place
> every time, with many important dependency failures.
>
>   https://hydra.gnu.org/build/2669344
>
> However, it's not obvious to me how best to work around the issue in
> this case.  Here's the error message:
>
> --8<---------------cut here---------------start------------->8---
> [ 36%] Building CXX object qtools/CMakeFiles/qtools.dir/qutfcodec.cpp.o
> cd /tmp/guix-build-doxygen-1.8.13.drv-0/build/qtools && /gnu/store/
> cd5q2pni1d95fs3cdabbclyh9hqhw2nq-gcc-5.5.0/bin/c++   -I/gnu/store/
> zjgd0wcbwxz8469skx5s83kibycf1n5p-glibc-2.27/include
> -I/tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/.  -O2 -g
> -DNDEBUG   -o CMakeFiles/qtools.dir/qutfcodec.cpp.o -c
> /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfcodec.cpp
> /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfcodec.cpp:
> In member function ‘virtual QCString QUtf16Encoder::fromUnicode(const
> QString&, int&)’:
> /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfcodec.cpp:212:61:
> internal compiler error: Segmentation fault
>       memcpy(d.rawData(),&QChar::byteOrderMark,sizeof(QChar));
>                                                              ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [qtools/CMakeFiles/qtools.dir/build.make:391:
> qtools/CMakeFiles/qtools.dir/qutfcodec.cpp.o] Error 1
> --8<---------------cut here---------------end--------------->8---
>
> Here's the declaration of QChar::byteOrderMark from qtools/qstring.h,
> included in the doxygen tarball:
>
> --8<---------------cut here---------------start------------->8---
> class Q_EXPORT Q_PACKED QChar {
> public:
>     QChar();
>     QChar( char c );
>     QChar( uchar c );
>     QChar( uchar c, uchar r );
>     QChar( const QChar& c );
>     QChar( ushort rc );
>     QChar( short rc );
>     QChar( uint rc );
>     QChar( int rc );
>
>     QT_STATIC_CONST QChar null;            // 0000
>     QT_STATIC_CONST QChar replacement;     // FFFD
>     QT_STATIC_CONST QChar byteOrderMark;     // FEFF
>     QT_STATIC_CONST QChar byteOrderSwapped;     // FFFE
>     QT_STATIC_CONST QChar nbsp;            // 00A0
> --8<---------------cut here---------------end--------------->8---
>
> and here's its definition, from qtools/qstring.cpp line 12179:
>
>   QT_STATIC_CONST_IMPL QChar QChar::byteOrderMark((ushort)0xfeff);
>
> Any suggestions?  I've managed to avoid working with C++ so far in this
> millenium, so I'm a bit rusty.
>
>
I'm willing to investigate the possibilities we have in this case. Can you
help me reproduce this, if it is still a problem?



>      Mark
>
>
>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.