From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC segfaults Date: Fri, 8 Jun 2018 12:04:03 +0200 Message-ID: References: <87k1reuc4r.fsf@gnu.org> <87sh623v4a.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000b8bc5056e1e858a" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fREGb-0001p5-Ok for bug-guix@gnu.org; Fri, 08 Jun 2018 06:05:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fREGV-0006T6-2U for bug-guix@gnu.org; Fri, 08 Jun 2018 06:05:09 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:59143) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fREGU-0006T1-Tn for bug-guix@gnu.org; Fri, 08 Jun 2018 06:05:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fREGU-0001K0-Hw for bug-guix@gnu.org; Fri, 08 Jun 2018 06:05:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87sh623v4a.fsf@netris.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 31708@debbugs.gnu.org --0000000000000b8bc5056e1e858a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-06-05 3:00 GMT+02:00 Mark H Weaver : > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > > On current =E2=80=98core-updates=E2=80=99, we have: > > > > $ readlink -f $(type -P gcc) > > /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc > > ludo@ribbon /home/ludo/src/guix/+core-updates$ cat strmov-ice.c > > #define _GNU_SOURCE > > #include > > > > 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 =E2=80=98foo=E2=80=99: > > 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 =E2=80=98buf=E2=80= =99, but > > =E2=80=98store_reference_p=E2=80=99 doesn=E2=80=99t check whether we go= t 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 > > > > void foo (char *x) > > { > > static const char buf[12] =3D { 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 =C3=A2=E2=82=AC=CB=9Cvirtual QCString QUtf16Encoder::f= romUnicode(const > QString&, int&)=C3=A2=E2=82=AC=E2=84=A2: > /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 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 > > > > --0000000000000b8bc5056e1e858a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -06-05 3:00 GMT+02:00 Mark H Weaver <mhw@netris.org>:
l= udo@gnu.org (Ludovic Court=C3=A8s) writes:

> On current =E2=80=98core-updates=E2=80=99, we have:
>
> $ readlink -f $(type -P gcc)
> /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gc= c
> ludo@ribbon /home/ludo/src/guix/+core-updates$ cat strmov-ice.c > #define _GNU_SOURCE
> #include <string.h>
>
> void foo (char *x)
> {
>=C2=A0 =C2=A0static const char buf[12];
>=C2=A0 =C2=A0memcpy (x, buf, 12);
> }
> $ gcc -dH -O2 -Wall -c strmov-ice.c
> strmov-ice.c: In function =E2=80=98foo=E2=80=99:
> strmov-ice.c:7:3: internal compiler error: Segmentation fault
>=C2=A0 =C2=A0 memcpy (x, buf, 12);
>=C2=A0 =C2=A0 ^
> gcc: internal compiler error: Aborted (program cc1)

[...]

> This is because DECL_INITIAL returns NULL_TREE for =E2=80=98buf=E2=80= =99, but
> =E2=80=98store_reference_p=E2=80=99 doesn=E2=80=99t check whether we g= ot 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 arra= y:
>
> $ cat strmov-ice.c
> #define _GNU_SOURCE
> #include <string.h>
>
> void foo (char *x)
> {
>=C2=A0 =C2=A0static const char buf[12] =3D { 0, };
>=C2=A0 =C2=A0memcpy (x, buf, 12);
> }
> $ gcc -dH -O2 -Wall -c strmov-ice.c
> $ echo $?
> 0
>
> The meaning of the program is unchanged but th= e bug is not triggered.

Thanks for tracking this down.=C2=A0 This explains why I've been= seeing an
unusually large number of internal compiler errors in this core-updates
cycle.=C2=A0 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.

=C2=A0 https://hydra.gnu.org/build/2669344

However, it's not obvious to me how best to work around the issue in this case.=C2=A0 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/s= tore/cd5q2pni1d95fs3cdabbclyh9hqhw2nq-gcc-5.5.0/bin/c++=C2=A0 =C2= =A0-I/gnu/store/zjgd0wcbwxz8469skx5s83kibycf1n5p-glibc-2.27/inclu= de -I/tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/.= =C2=A0 -O2 -g -DNDEBUG=C2=A0 =C2=A0-o CMakeFiles/qtools.dir/qutfcodec.= cpp.o -c /tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtoo= ls/qutfcodec.cpp
/tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfco= dec.cpp: In member function =C3=A2=E2=82=AC=CB=9Cvirtual QCString QUtf16Enc= oder::fromUnicode(const QString&, int&)=C3=A2=E2=82=AC=E2=84= =A2:
/tmp/guix-build-doxygen-1.8.13.drv-0/doxygen-1.8.13/qtools/qutfco= dec.cpp:212:61: internal compiler error: Segmentation fault
=C2=A0 =C2=A0 =C2=A0 memcpy(d.rawData(),&QChar::byteOrderMark,size= of(QChar));
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
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: qtoo= ls/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:
=C2=A0 =C2=A0 QChar();
=C2=A0 =C2=A0 QChar( char c );
=C2=A0 =C2=A0 QChar( uchar c );
=C2=A0 =C2=A0 QChar( uchar c, uchar r );
=C2=A0 =C2=A0 QChar( const QChar& c );
=C2=A0 =C2=A0 QChar( ushort rc );
=C2=A0 =C2=A0 QChar( short rc );
=C2=A0 =C2=A0 QChar( uint rc );
=C2=A0 =C2=A0 QChar( int rc );

=C2=A0 =C2=A0 QT_STATIC_CONST QChar null;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 // 0000
=C2=A0 =C2=A0 QT_STATIC_CONST QChar replacement;=C2=A0 =C2=A0 =C2=A0// FFFD=
=C2=A0 =C2=A0 QT_STATIC_CONST QChar byteOrderMark;=C2=A0 =C2=A0 =C2=A0// FE= FF
=C2=A0 =C2=A0 QT_STATIC_CONST QChar byteOrderSwapped;=C2=A0 =C2=A0 =C2=A0//= FFFE
=C2=A0 =C2=A0 QT_STATIC_CONST QChar nbsp;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 // 00A0
--8<---------------cut here---------------end--------------->8--= -

and here's its definition, from qtools/qstring.cpp line 12179:

=C2=A0 QT_STATIC_CONST_IMPL QChar QChar::byteOrderMark((ushort)0xfeff)= ;

Any suggestions?=C2=A0 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= ?

=C2=A0
=C2=A0 =C2=A0 =C2=A0Mark




--0000000000000b8bc5056e1e858a--