[Bug libc/25820] New: General protection fault in `sysdeps/x86_64/crti.S`

[Bug libc/25820] New: General protection fault in `sysdeps/x86_64/crti.S`

[pmenzel+sourceware.org-bugzilla at molgen dot mpg.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25820

            Bug ID: 25820
           Summary: General protection fault in `sysdeps/x86_64/crti.S`
           Product: glibc
           Version: 2.27
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: pmenzel+sourceware.org-bugzilla at molgen dot mpg.de
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Note, this error might be due to a processor bug in AMD Zen (Ryzen) systems.

The script `kill-ryzen.sh` [1] builds GCC 7.2.0 `nproc` times in parallel with
one thread each in a loop to reproduce a processor bug in AMD Ryzen CPUs.

On a Dell OptiPlex 5055 with AMD Ryzen 5 PRO 1500 Quad-Core Processor
(microcode patch level 0x08001137), and Linux 5.6, the crash below happened.

    [loop-6] TIME TO FAIL: 190004 s
    [KERN] 2020-04-11T16:05:05+0200 deinhandtuch.molgen.mpg.de kernel: traps:
xgcc[22581] general protection fault ip:41bdc9 sp:7fff35456a10 error:0 in
xgcc[403000+bf000]

Here is the line from `dmesg`.

    [190279.006479] traps: xgcc[22581] general protection fault ip:41bdc9
sp:7fff35456a10 error:0 in xgcc[403000+bf000]

The same code has been built in several loops before, so it’s not reproducible.

The step below failed.

   
source='/scratch/local/ryzen-test/gcc-7.2.0/libdecnumber/bid/bid2dpd_dpd2bid.c'
object='bid2dpd_dpd2bid.o' libtool=no
/scratch/local/ryzen-test/buildloop.d/loop-6/./prev-gcc/xgcc
-B/scratch/local/ryzen-test/buildloop.d/loop-6/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include    
-I/scratch/local/ryzen-test/gcc-7.2.0/libdecnumber -I.  -g -O2 -gtoggle -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
-Wno-long-long  -fno-lto -I/scratch/local/ryzen-test/gcc-7.2.0/libdecnumber -I.
  -c /scratch/local/ryzen-test/gcc-7.2.0/libdecnumber/bid/bid2dpd_dpd2bid.c
    make[3]: *** [Makefile:147: bid2dpd_dpd2bid.o] Segmentation fault (core
dumped)

Trying to find the corresponding source from xgcc[403000+bf000] gives:

    $ addr2line -e ./buildloop.d/loop-0/prev-gcc/xgcc -a 403000+bf000
    0x0000000000403000
   
/scratch/local/bee-root/glibc/glibc-2.27-0/source/csu/../sysdeps/x86_64/crti.S:64

    $ ls -lh glibc-2.27-0.x86_64/source/sysdeps/x86_64/crti.S
    -rw-rw---- 1 joey joey 2.7K Feb  1  2018
glibc-2.27-0.x86_64/source/sysdeps/x86_64/crti.S

Here are the lines:

 52 #if PREINIT_FUNCTION_WEAK
 53         weak_extern (PREINIT_FUNCTION)
 54 #else
 55         .hidden PREINIT_FUNCTION
 56 #endif
 57 
 58         .section .init,"ax",@progbits
 59         .p2align 2
 60         .globl _init
 61         .type _init, @function
 62 _init:
 63         /* Maintain 16-byte stack alignment for called functions.  */
 64         subq $8, %rsp
 65 #if PREINIT_FUNCTION_WEAK
 66         movq PREINIT_FUNCTION@GOTPCREL(%rip), %rax
 67         testq %rax, %rax
 68         je .Lno_weak_fn
 69         call *%rax
 70 .Lno_weak_fn:
 71 #else
 72         call PREINIT_FUNCTION
 73 #endif

Changes in later versions in that file do not seem to be related to the
problem.

Can `subq $8, %rsp` cause a general protection fault, or does it point to a CPU
issue?

[1]: https://github.com/Oxalin/ryzen-test/
[2]:
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/x86_64/crti.S;h=c2f1cc3c951ccf1338706ce9d39249da110a036d;hb=HEAD

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/25820] General protection fault in `sysdeps/x86_64/crti.S`

[fw at deneb dot enyo.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25820

Florian Weimer <fw at deneb dot enyo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |fw at deneb dot enyo.de
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-04-14

--- Comment #1 from Florian Weimer <fw at deneb dot enyo.de> ---
You passed the wrong address to addr2line.  Per the kernel message, the
faulting instruction seems to be at 0x41bdc9, not 0x403000.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/25820] General protection fault in `sysdeps/x86_64/crti.S`

[pmenzel+sourceware.org-bugzilla at molgen dot mpg.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25820

--- Comment #2 from Paul Menzel <pmenzel+sourceware.org-bugzilla at molgen dot mpg.de> ---
Thank you. Sorry about that.

    $ addr2line -e ./buildloop.d/loop-0/prev-gcc/xgcc -a 41bdc9
    0x000000000041bdc9
    /scratch/local/ryzen-test/gcc-7.2.0/gcc/prefix.c:278

```
[…]
246 char *
247 update_path (const char *path, const char *key)
248 {
249   char *result, *p;
250   const int len = strlen (std_prefix);
251 
252   if (! filename_ncmp (path, std_prefix, len)
253       && (IS_DIR_SEPARATOR (path[len])
254           || path[len] == '\0')
255       && key != 0)
256     { 
257       bool free_key = false;
258       
259       if (key[0] != '$')
260         { 
261           key = concat ("@", key, NULL);
262           free_key = true;
263         }
264       
265       result = concat (key, &path[len], NULL);
266       if (free_key)
267         free (CONST_CAST (char *, key));
268       result = translate_name (result);
269     } 
270   else
271     result = xstrdup (path);
272 
273   p = result;
274   while (1)
275     { 
276       char *src, *dest;
277 
278       p = strchr (p, '.');
279       if (p == NULL)
280         break;
281       /* Look for `/../'  */
282       if (p[1] == '.'
[…]
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/25820] General protection fault in `sysdeps/x86_64/crti.S`

[fw at deneb dot enyo.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25820

Florian Weimer <fw at deneb dot enyo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
              Flags|                            |security-
         Resolution|---                         |INVALID

--- Comment #3 from Florian Weimer <fw at deneb dot enyo.de> ---
Okay, so it is not a glibc bug. You will have to diagnose this further. I do
not see immediately how there can be a fault at line 278, even if strchr is
expanded inline.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/25820] General protection fault on AMD Ryzen

[pmenzel+sourceware.org-bugzilla at molgen dot mpg.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25820

Paul Menzel <pmenzel+sourceware.org-bugzilla at molgen dot mpg.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|General protection fault in |General protection fault on
                   |`sysdeps/x86_64/crti.S`     |AMD Ryzen

--- Comment #4 from Paul Menzel <pmenzel+sourceware.org-bugzilla at molgen dot mpg.de> ---
Thanks. I am out of my depth here. Do you have a suggestion? Contact the GCC
folks, or the LKML?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/25820] General protection fault on AMD Ryzen

[fw at deneb dot enyo.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=25820

--- Comment #5 from Florian Weimer <fw at deneb dot enyo.de> ---
I'd suggest to look at a coredump or add error logging, to see what went wrong
at that. My hunch is that it's more likely to be a GCC issue. But the GCC
people will definitely need more data than just the location of the crash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.