[Bug go/66303] New: runtime.Caller() returns infinitely deep stack frames on s390x

[Bug go/66303] New: runtime.Caller() returns infinitely deep stack frames on s390x

[e29253 at jp dot ibm.com]

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

            Bug ID: 66303
           Summary: runtime.Caller() returns infinitely deep stack frames
                    on s390x
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: e29253 at jp dot ibm.com
                CC: cmang at google dot com
  Target Milestone: ---

Created attachment 35633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35633&action=edit
Sample program

The function runtime.Caller() returns infinitely deep stack frames on s390x
when we increase the argument 'skip'. 

Attached sample program does not terminate when we ran with GCCGO on s390x:
[inagaki@inagaki caller]$ go version
go version go1.4.2 gccgo (GCC) 5.1.1 20150527 linux/s390x
[inagaki@inagaki caller]$ go run caller.go | head
pc=4397991940204, file=../../../src/libgo/runtime/proc.c, line=235, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
pc=4397981455530, file=, line=0, ok=true
^Cexit status 2
[inagaki@inagaki caller]$

The same program terminates with GC on x86_64:
-bash-4.1$ go version
go version go1.4.2 linux/amd64
-bash-4.1$ go run caller.go
pc=4329617, file=/usr/local/go/src/runtime/asm_amd64.s, line=2232, ok=true
pc=0, file=, line=0, ok=false
-bash-4.1$

Is it valid usage to detect a stack bottom by the return value 'ok'?

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> ---
The one valid entry in the backtrace is in the function kickoff in proc.c. 
That function is supposed to stop the trace.  Search for "kickoff" in
libgo/runtime/go-callers.c.  The question is why that didn't work.  Can you set
a breakpoint on that code, or add some print statements, and find out the value
of the local variable function?

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[e29253 at jp dot ibm.com]

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

--- Comment #3 from Tatsushi Inagaki <e29253 at jp dot ibm.com> ---
Created attachment 35641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35641&action=edit
gdb session of callback() called from runtime.Caller(skip==3)

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[e29253 at jp dot ibm.com]

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

--- Comment #2 from Tatsushi Inagaki <e29253 at jp dot ibm.com> ---
The first invocation of runtime.Caller() with skip==2 successfully detects
kickoff() in callback(), and thus returns ok==true.

The problem is that the succeeding invocations of runtime.Caller() with
skip==3, 4, 5, ... still continue returning ok==true. This is because
callback() returns index==1 and a non-zero pc, which are recognized as valid
information by runtime.Caller() in runitme/go-caller.c. I attached a gdb
session of the second invocation of runtime.Caller() with skip==3.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[vogt at linux dot vnet.ibm.com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vogt at linux dot vnet.ibm.com

--- Comment #4 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
I think the problem is that in the backtrace below
_Unwind_Find_registered_FDE() is called with a pc that points one byte before
the start of main.main (0x80001de8).  That is cause by this line from
uw_frame_state_for():

  fde = _Unwind_Find_FDE (context->ra + _Unwind_IsSignalFrame (context) - 1,
                          &context->bases);

-- snip --
#0  _Unwind_Find_registered_FDE (bases=0xc2084176e0, 
    pc=0x80001de7 <main.main+23>) at ../../../libgcc/unwind-dw2-fde.c:1010
#1  _Unwind_Find_FDE (pc=0x80001de7 <main.main+23>, bases=0xc2084176e0)
    at ../../../libgcc/unwind-dw2-fde-dip.c:454
#2  0x000003fff6ee665c in uw_frame_state_for (
    context=context@entry=0xc2084175b0, fs=fs@entry=0xc208417738)
    at ../../../libgcc/unwind-dw2.c:1241
#3  0x000003fff6ee8442 in _Unwind_Backtrace (trace=0x3fff7aca438 <unwind>, 
    trace_argument=0xc208417aa8) at ../../../libgcc/unwind.inc:290
#4  0x000003fff7aca51a in backtrace_full (state=<optimized out>, 
    skip=<optimized out>, callback=<optimized out>, 
    error_callback=<optimized out>, data=0xc208417b78)
    at ../../../libbacktrace/backtrace.c:106
#5  0x000003fff7773a16 in runtime_callers (skip=<optimized out>, 
    locbuf=<optimized out>, m=<optimized out>, keep_thunks=<optimized out>)
    at ../../../libgo/runtime/go-callers.c:168
#6  0x000003fff777356c in runtime.Caller (skip=skip@entry=20)
    at ../../../libgo/runtime/go-caller.c:168
#7  0x0000000080001de8 in main.main () at pr66303.go:9
-- snip --

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Funny, the backtrace claims that 0x80001de7 ist main.main+23 (#0 of the
backtrace), but it actually is main.main-1 (#7).

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Ah, forget it, the addresses are okay; I'll dig deeper into the code.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[vogt at linux dot vnet.ibm.com]

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

--- Comment #7 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
When dumping the complete backtrace, gdb produces a warning.  Maybe the
libgo/runtime code does not properly set up the initial stack frame of the
thread?

(gdb) set backtrace past-main 
(gdb) bt
#0  main.main () at pr66303.go:8
#1  0x000003fff778a538 in runtime_main (dummy=<optimized out>)
    at ../../../libgo/runtime/proc.c:626
#2  0x000003fff77879c4 in kickoff () at ../../../libgo/runtime/proc.c:235
#3  0x000003fff6d89ca2 in __makecontext_ret () from /lib64/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[ian at airs dot com]

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

--- Comment #8 from Ian Lance Taylor <ian at airs dot com> ---
The initial stack frame of a goroutine is set up by the makecontext function,
which is part of the C library.  Ideally makecontext should arrange matters
such that a backtrace stops at that point, as pthread_create does.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
The problem is reproduceable with the makecontext C testcases in Glibc (with
some manual intervention).  So, this isn't a Go related problem.  Our analysis
so far seems to indicate that it's a bug in the s390x specific code of Glibc or
maybe the s390x unwinding code in libgcc (less likely).  We'll take care of the
problem.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[vogt at linux dot vnet.ibm.com]

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

--- Comment #10 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Just a short update before the bank holiday weekend in Germany.  The problem is
caused by missing cfi directives in the Glibc sources.  We'll open a Glibc bug
report and provide a patch next week.

Gdb has some safety checks in its unwinding code to catch such pathological
situations.  It might be worthwhile to add something similar to the unwinding
code in libgcc.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[stli at linux dot vnet.ibm.com]

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

stli at linux dot vnet.ibm.com <stli at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stli at linux dot vnet.ibm.com

--- Comment #11 from stli at linux dot vnet.ibm.com <stli at linux dot vnet.ibm.com> ---
I have created a bug in glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=18508

and posted a patch
(https://www.sourceware.org/ml/libc-alpha/2015-06/msg00324.html) which omits
the cfi_startproc/cfi_endproc directives for __makecontext_ret. Thus backtrace
do not find any information about __makecontext_ret in .eh_frame and stops
backtrace like it is done with _start and thread_start functions.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[stli at linux dot vnet.ibm.com]

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

--- Comment #12 from stli at linux dot vnet.ibm.com <stli at linux dot vnet.ibm.com> ---
The glibc bug https://sourceware.org/bugzilla/show_bug.cgi?id=18508
is fixed upstream with commit
https://sourceware.org/git/?p=glibc.git;a=commit;h=890b7a4b33d482b5c768ab47d70758b80227e9bc

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel <krebbel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #15 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
Closing. Fixed in Glibc.