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

Previous Next

Package: guix;

Reported by: ludo <at> gnu.org (Ludovic Courtès)

Date: Mon, 4 Jun 2018 09:37:01 UTC

Severity: important

Tags: fixed

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31708 in the body.
You can then email your comments to 31708 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Mon, 04 Jun 2018 09:37:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to ludo <at> gnu.org (Ludovic Courtès):
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Mon, 04 Jun 2018 09:37:01 GMT) Full text and rfc822 format available.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guix <at> gnu.org
Subject: 'gcc-strmov-store-file-names.patch' causes GCC segfaults
Date: Mon, 04 Jun 2018 11:36:20 +0200
Hello,

On current ‘core-updates’, we have:

--8<---------------cut here---------------start------------->8---
$ 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)
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.1
Copyright (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 ()
--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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’.




Severity set to 'important' from 'normal' Request was from ludo <at> gnu.org (Ludovic Courtès) to control <at> debbugs.gnu.org. (Mon, 04 Jun 2018 09:55:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Tue, 05 Jun 2018 01:02:02 GMT) Full text and rfc822 format available.

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

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 31708 <at> debbugs.gnu.org
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Mon, 04 Jun 2018 21:00:37 -0400
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.

     Mark




Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Tue, 05 Jun 2018 22:27:01 GMT) Full text and rfc822 format available.

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

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 31708 <at> debbugs.gnu.org
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Tue, 05 Jun 2018 18:24:43 -0400
Mark H Weaver <mhw <at> 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.

       Mark




Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Wed, 06 Jun 2018 13:31:02 GMT) Full text and rfc822 format available.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31708 <at> debbugs.gnu.org
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Wed, 06 Jun 2018 15:29:52 +0200
Hi Mark,

Mark H Weaver <mhw <at> netris.org> skribis:

> Mark H Weaver <mhw <at> 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’t
great.

If there are few ICEs, maybe we can just fix them individually.

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Fri, 08 Jun 2018 10:05:02 GMT) Full text and rfc822 format available.

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)]

Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Fri, 08 Jun 2018 13:27:03 GMT) Full text and rfc822 format available.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31708 <at> debbugs.gnu.org
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Fri, 08 Jun 2018 15:26:12 +0200
Hi Mark,

Mark H Weaver <mhw <at> 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.)

Thanks for the heads-up,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Fri, 08 Jun 2018 18:13:02 GMT) Full text and rfc822 format available.

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

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 31708 <at> debbugs.gnu.org
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Fri, 08 Jun 2018 14:11:20 -0400
ludo <at> gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw <at> 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




Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Fri, 08 Jun 2018 19:35:02 GMT) Full text and rfc822 format available.

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

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

Gábor Boskovits <boskovits <at> gmail.com> skribis:

> 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 earlier
today.  Thanks for the offer though!

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#31708; Package guix. (Wed, 13 Jun 2018 21:07:02 GMT) Full text and rfc822 format available.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: 31708 <at> debbugs.gnu.org
Subject: Re: bug#31708: 'gcc-strmov-store-file-names.patch' causes GCC
 segfaults
Date: Wed, 13 Jun 2018 23:06:06 +0200
ludo <at> gnu.org (Ludovic Courtès) skribis:

> 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’, commit
243ea8673f783d5a85df94b09d4ffd4bc6cc97ce.

Ludo’.




Added tag(s) fixed. Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 05 Jan 2019 13:57:01 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 31708 <at> debbugs.gnu.org and ludo <at> gnu.org (Ludovic Courtès) Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 05 Jan 2019 13:57:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 03 Feb 2019 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 55 days ago.

Previous Next


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