[Bug go/114582] New: go.test/test/fixedbugs/issue34123.go FAILs

[Bug go/114582] New: go.test/test/fixedbugs/issue34123.go FAILs

[ro at gcc dot gnu.org]

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

            Bug ID: 114582
           Summary: go.test/test/fixedbugs/issue34123.go FAILs
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
            Target: sparc-sun-solaris2.11

The go.test/test/fixedbugs/issue34123.go test FAILs on 32-bit Solaris/SPARC
since it was introduced:

FAIL: go.test/test/fixedbugs/issue34123.go execution,  -O2 -g 

SIGABRT: abort
PC=0xfd799dc4 m=5 sigcode=4294967295

goroutine 1 [running]:
__lwp_sigqueue
        :0

As with PR go/114581, under gdb the code path is different:

Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00013a8c in main.f ()
    at
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:24
24              *q = 12 // line 24
(gdb) bt
#0  0x00013a8c in main.f ()
    at
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:24
#1  0x00013adc in main.main ()
    at
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:42
(gdb) p q
$1 = (uint8 *) 0x0
(gdb) cont
Continuing.
SIGSEGV: segmentation violation
PC=0x13600 m=0 sigcode=0

goroutine 1 [running]:
main.f
       
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:24
main.main
       
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue34123.go:42

This could well be a gdb issue, however: dbx behaves differently:

t@1 (l@1) signal SEGV (no mapping at the fault address) in main.f at 0x13600
0x00013600: f+0x000c:   stb      %g2, [%g1]
(dbx) cont -sig SEGV
t@1 (l@1) signal ABRT (Abort) in __lwp_sigqueue at 0xfd799dc4
0xfd799dc4: __lwp_sigqueue+0x0008:      bcc,a,pt  %icc,__lwp_sigqueue+0x18     
! 0xfd799dd4
(dbx) where
current thread: t@1
=>[1] __lwp_sigqueue(0x0, 0x1, 0x6, 0x0, 0xffffffffffffffff, 0x0), at
0xfd799dc4 
  [2] raise(0x6, 0x6, 0x5, 0x0, 0x0, 0x0), at 0xfd6d7570 
  [3] abort(0xfe362cd4, 0xfd7ec000, 0x64cae8, 0x474f0000, 0x41c180, 0x64d01c),
at 0xfd6a87b8 
  ---- hidden frames, use 'where -h' to see them all ----
  [6] throwException(0x400500, 0x0, 0x7, 0xff1e5950, 0xfe0e0758, 0xff1e0318),
at 0xfe363748 
  [7] gopanic(0x64d54c, 0x1, 0x696020, 0xfeec51f0, 0x400500, 0x64de48), at
0xfe9252e0 
  [8] panicmem(0xb, 0x64d8d0, 0x0, 0x0, 0xff, 0x64d6a0), at 0xfe9036fc 
  [9] sigpanic(0x0, 0x64d8d0, 0x0, 0x0, 0x0, 0x400500), at 0xfe90708c 
  [10] sigtrampgo(0xb, 0x64dd60, 0x64da80, 0x88, 0x64d8d0, 0x400500), at
0xfe91a46c 
  [11] __sighndlr(0xb, 0x64dd60, 0x64da80, 0xfe362cd4, 0x0, 0x1), at 0xfd794ee0 
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [12] main.f(0x64de48, 0x64de46, 0x13a30, 0x64de47, 0x6b20c0, 0x400500), at
0x13600 
  [13] main.main(0x418128, 0xfeec51f0, 0x418130, 0x400500, 0x64de60, 0x400500),
at 0x13ce0 
  [14] main(0xfeec0fcc, 0xfeec1b48, 0x40a138, 0x418440, 0x64dee2, 0xfe92a8e0),
at 0xfe92e7f8 
  [15] kickoff(0x0, 0x4007c8, 0xfe92952c, 0x0, 0x4007a4, 0x400500), at
0xfe925834

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> ---
The bug here, and also with PR 114581, is in unwinding from a signal call.  A
simplified version of the code for this issue is:

func main() {
    defer func() { recover() }()
    f()
}

func f() { *p = 0 }

The *p = 0 in f will raise a SIGSEGV.  The Go runtime will turn that into a
panic.  The recover in main will prevent that panic from killing the program.

The unwind code works by walking up the stack until it finds a recover.  When
it finds a recover, it records that stack frame as the end of the unwind.  It
runs the recover, then walks up the stack again to unwind it.  In the second
walk, it checks that it does not walk past the stack frame that calls recover.

Recording the stack frame is done based on what the signal handler calls the
CFA, which is, basically, the frame pointer.  It is also based on whether a
signal occurred in that frame.

In this test case, the function f is so simple that it has no frame.  That
turns out to mean that f's CFA is the same as main's CFA.  In the first stack
walk, we find main, and record main's CFA as the point where the second unwind
should stop.  In the second stack walk, when we get to f, we think we have
reached the end.  But we haven't, because we haven't reached main yet.  This
causes an assert, which shows up as a SIGABRT.

That is what happens today.  But it would work fine if we knew that a signal
occurred in f, as in fact it did.  However, we don't, because of this code in
libgcc/config/sol2-unwind.h:

  /* SIGFPE for IEEE-754 exceptions is delivered after the faulting insn
     rather than before it, so don't set fs->signal_frame in that case.
     We test whether the cexc field of the FSR is zero.  */
  if ((mctx->fpregs.fpu_fsr & 0x1f) == 0)
    fs->signal_frame = 1;

If we unconditionally set fs->signal_frame, as is done on Linux, this would
work.  And it works on 64-bit SPARC, because those flags turn out to be zero. 
But on 32-bit SPARC, they are not zero.  Specifically, bit 0 is set, indicating
that an inexact operation occurred.  I don't know why.

That code was added by
https://gcc.gnu.org/legacy-ml/gcc-patches/2013-05/msg01390.html.  If I undo
that change, so that fs->signal_frame is set unconditionally as it was before,
then the Go test passes.

I don't know why it is reasonable to assume that if the floating-point inexact
flag is set then the signal is a floating-point signal.  In this case that is
clearly incorrect.

Because the problem here appears to be a Solaris-specific problem with
Solaris-specific code, I don't plan to work any further on it.

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
*** Bug 114581 has been marked as a duplicate of this bug. ***

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
*** Bug 114583 has been marked as a duplicate of this bug. ***

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
*** Bug 114584 has been marked as a duplicate of this bug. ***

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org
   Last reconfirmed|                            |2024-05-03
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Rather weird, given that there is apparently no FP in the code.  The (kludgy)
way out could be to exclude the inexact flag from the test, as I don't think
that people really care about exceptions on inexact results in practice.

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
There is no floating-point in the user code, but Go does have a runtime that
runs at the start of every program, and it is possible that that code uses some
floating-point operations.  In particular by default memory allocation randomly
profiles a small number of operations, and determining whether to do a random
profile appears to involve floating-point operations
(libgo/go/runtime/fastlog2.go).