'gcc-strmov-store-file-names.patch' causes GCC segfaults

DoneSubmitted by Ludovic Courtès.
Details
3 participants
  • Gábor Boskovits
  • Ludovic Courtès
  • Mark H Weaver
Owner
unassigned
Severity
important
L
L
Ludovic Courtès wrote on 4 Jun 2018 11:36
(address . bug-guix@gnu.org)
87k1reuc4r.fsf@gnu.org
Hello,
On current ‘core-updates’, we have:
Toggle snippet (71 lines)$ readlink -f $(type -P gcc)/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gccludo@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.cstrmov-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)Please submit a full bug report,with preprocessed source if appropriate.See <http://gcc.gnu.org/bugs.html> for instructions.$ gdb /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/libexec/gcc/x86_64-unknown-linux-gnu/5.5.0/cc1 core GNU gdb (GDB) 8.1Copyright (C) 2018 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-unknown-linux-gnu".Type "show configuration" for configuration details.For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.Find the GDB manual and other documentation resources online at:<http://www.gnu.org/software/gdb/documentation/>.For help, type "help".Type "apropos word" to search for commands related to "word"...Reading symbols from /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/libexec/gcc/x86_64-unknown-linux-gnu/5.5.0/cc1...(no debugging symbols found)...done.[New LWP 1694]Core was generated by `/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/libexec/gcc/x86_64-unknow'.Program terminated with signal SIGABRT, Aborted.#0 0x00007fc415d8ba50 in raise () from /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/libc.so.6(gdb) bt#0 0x00007fc415d8ba50 in raise () from /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/libc.so.6#1 0x00007fc415d8cc31 in abort () from /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/libc.so.6#2 0x0000000000f947ab in diagnostic_action_after_output(diagnostic_context*, diagnostic_t) ()#3 0x0000000000f94a60 in diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ()#4 0x0000000000f95a88 in internal_error(char const*, ...) ()#5 0x00000000009e9b40 in crash_signal(int) ()#6 <signal handler called>#7 0x00000000006b3404 in store_reference_p(tree_node*) ()#8 0x00000000007f4880 in gimple_fold_builtin_memory_op(gimple_stmt_iterator*, tree_node*, tree_node*, int) ()#9 0x00000000007f643e in gimple_fold_builtin(gimple_stmt_iterator*) ()#10 0x00000000007f8cf4 in fold_stmt_1(gimple_stmt_iterator*, bool, tree_node* (*)(tree_node*)) ()#11 0x0000000000843c68 in gimplify_call_expr(tree_node**, gimple_statement_base**, bool) ()#12 0x000000000083f5c8 in gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ()#13 0x0000000000840ad7 in gimplify_stmt(tree_node**, gimple_statement_base**) ()#14 0x000000000083effc in gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ()#15 0x0000000000840ad7 in gimplify_stmt(tree_node**, gimple_statement_base**) ()#16 0x00000000008412de in gimplify_bind_expr(tree_node**, gimple_statement_base**) ()#17 0x000000000083f5aa in gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ()#18 0x0000000000840ad7 in gimplify_stmt(tree_node**, gimple_statement_base**) ()#19 0x0000000000841982 in gimplify_body(tree_node*, bool) ()#20 0x0000000000841ca8 in gimplify_function_tree(tree_node*) ()#21 0x00000000006fa268 in cgraph_node::analyze() ()#22 0x00000000006fc870 in analyze_functions() ()#23 0x00000000006fccb8 in symbol_table::finalize_compilation_unit() ()#24 0x0000000000611183 in c_write_global_declarations() ()#25 0x00000000009e9bd3 in compile_file() ()#26 0x00000000005f0214 in toplev::main(int, char**) ()#27 0x00000000005f0f7e in main ()
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 meantimewe need to work around it.
A simple workaround is to pass an initializer to the static const array:
Toggle snippet (14 lines)$ 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.
“Apologies for the inconvenience and thank you for your understanding”as they say.
Ludo’.
L
L
Ludovic Courtès wrote on 4 Jun 2018 11:53
control message for bug #31708
(address . control@debbugs.gnu.org)
87in6yubbe.fsf@gnu.org
severity 31708 important
M
M
Mark H Weaver wrote on 5 Jun 2018 03:00
Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC segfaults
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 31708@debbugs.gnu.org)
87sh623v4a.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (20 lines)> On current ‘core-updates’, 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 <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)
[...]
Toggle quote (23 lines)> 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 anunusually large number of internal compiler errors in this core-updatescycle. It was a bit surprising since we used the same compiler in theprevious 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 placeevery 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 inthis case. Here's the error message:
Toggle snippet (12 lines)[ 36%] Building CXX object qtools/CMakeFiles/qtools.dir/qutfcodec.cpp.ocd /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
Here's the declaration of QChar::byteOrderMark from qtools/qstring.h,included in the doxygen tarball:
Toggle snippet (19 lines)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
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 thismillenium, so I'm a bit rusty.
Mark
M
M
Mark H Weaver wrote on 6 Jun 2018 00:24
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 31708@debbugs.gnu.org)
87602w3m8k.fsf@netris.org
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (28 lines)> Here's the declaration of QChar::byteOrderMark from qtools/qstring.h,> included in the doxygen tarball:>> 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>> 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.
If some of these cases are difficult to work around, one option would beto add a new 'gcc-final/fixed' package or similar, with this bug fixed,and we could then add it as a 'native-input' to selected packages whereit's needed, e.g. doxygen on armhf.
Mark
L
L
Ludovic Courtès wrote on 6 Jun 2018 15:29
(name . Mark H Weaver)(address . mhw@netris.org)(address . 31708@debbugs.gnu.org)
877encjb5b.fsf@gnu.org
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
Toggle quote (35 lines)> Mark H Weaver <mhw@netris.org> writes:>>> Here's the declaration of QChar::byteOrderMark from qtools/qstring.h,>> included in the doxygen tarball:>>>> 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>>>> 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.>> If some of these cases are difficult to work around, one option would be> to add a new 'gcc-final/fixed' package or similar, with this bug fixed,> and we could then add it as a 'native-input' to selected packages where> it's needed, e.g. doxygen on armhf.
We could do that, though that means one more GCC to build, which isn’tgreat.
If there are few ICEs, maybe we can just fix them individually.
Ludo’.
G
G
Gábor Boskovits wrote on 8 Jun 2018 12:04
(name . Mark H Weaver)(address . mhw@netris.org)
CAE4v=pjMs5=H-4h=YqxAR79tYk=VK1frqkHfBsAtSFpv7awgUg@mail.gmail.com
2018-06-05 3:00 GMT+02:00 Mark H Weaver <mhw@netris.org>:
Toggle quote (114 lines)> ludo@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@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 youhelp me reproduce this, if it is still a problem?


Toggle quote (5 lines)> Mark>>>>
Attachment: file
L
L
Ludovic Courtès wrote on 8 Jun 2018 15:26
(name . Mark H Weaver)(address . mhw@netris.org)(address . 31708@debbugs.gnu.org)
87o9glmmtn.fsf@gnu.org
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
Toggle quote (4 lines)> 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.
Fixed very elegantly in commit 849a1399ca46497ad6acc5b11903f345502c02de.
The fact that it’s C++ makes things a little bit more complicated, andit makes the bug a little bit more likely to trigger (because in C++ youcan have declarations of ‘static const’ things, and a declarationdoesn’t have an initializer, hence the NULL pointer dereference.)
Thanks for the heads-up,Ludo’.
M
M
Mark H Weaver wrote on 8 Jun 2018 20:11
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 31708@debbugs.gnu.org)
87h8mdp2rb.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (13 lines)> Mark H Weaver <mhw@netris.org> skribis:>>> 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.>> Fixed very elegantly in commit 849a1399ca46497ad6acc5b11903f345502c02de.>> The fact that it’s C++ makes things a little bit more complicated, and> it makes the bug a little bit more likely to trigger (because in C++ you> can have declarations of ‘static const’ things, and a declaration> doesn’t have an initializer, hence the NULL pointer dereference.)
Looks good. Thank you, Ludovic!
Mark
L
L
Ludovic Courtès wrote on 8 Jun 2018 21:34
(name . Gábor Boskovits)(address . boskovits@gmail.com)
87tvqdhy2s.fsf@gnu.org
Hi Gábor,
Gábor Boskovits <boskovits@gmail.com> skribis:
Toggle quote (3 lines)> I'm willing to investigate the possibilities we have in this case. Can you> help me reproduce this, if it is still a problem?
Oops, I’m seeing your message just now and I fixed the issue earliertoday. Thanks for the offer though!
Ludo’.
L
L
Ludovic Courtès wrote on 13 Jun 2018 23:06
(address . 31708@debbugs.gnu.org)
87k1r2o0qp.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:
Toggle quote (6 lines)> 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.
I pushed a fix in ‘core-updates’, commit243ea8673f783d5a85df94b09d4ffd4bc6cc97ce.
Ludo’.
L
L
Ludovic Courtès wrote on 5 Jan 2019 14:56
control message for bug #31708
(address . control@debbugs.gnu.org)
87va335htv.fsf@gnu.org
tags 31708 fixedclose 31708
?
Your comment

This issue is archived.

To comment on this conversation send email to 31708@debbugs.gnu.org