[Bug go/65813] New: GO: bug347.go segment violation on S390x

[Bug go/65813] New: GO: bug347.go segment violation on S390x

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813

            Bug ID: 65813
           Summary: GO: bug347.go segment violation on S390x
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: vogt at linux dot vnet.ibm.com
                CC: cmang at google dot com

With current code from gcc_5_branch, the Go test bug347.go crashes by
dereferencing a null pointer:

-- snip --
$ gdb ./bug347.x
(gdb) run
Starting program: /home/vogt/src/git/gcc/build-go/gcc/testsuite/go/bug347.x 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x3fffaaa5910 (LWP 47868)]
[New Thread 0x3fffbba5910 (LWP 47867)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffaaa5910 (LWP 47868)]
0x00000000800019b8 in main.f ()
    at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:22
22        case <-t.c:  // THIS IS LINE 22
(gdb) bt
#0  0x00000000800019b8 in main.f ()
    at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:22
#1  0x0000000080001a8c in main.main ()
    at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:48
(gdb) p main.t
$1 = (struct {...} *) 0x0
-- snip --

It just dumps a core file and never calls the defered function (GOTRACEBACK is
not set).

[Bug go/65813] GO: bug347.go segment violation on S390x

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> ---
I think you know this, but to be clear, the test is supposed to dereference a
null pointer, and then it's supposed to recover from the run time panic.

The program should unwind the stack for the signal and call __go_check_defer
which should invoke the deferred function.  Can you find out where that process
is going awry?

If the recover* tests pass, then this test ought to pass, or at least it ought
not to fail in this way.

[Bug go/65813] GO: bug347.go segment violation on S390x

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813

Dominik Vogt <vogt at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Sorry, this turned out to be the same problem we had with Glibc a while ago. 
Somehow the broken Glibc had been reactivated.  Not a Go or Gcc problem.