Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: after g0.stack is adjusted in x_cgo_init(), g0.stack.lo cannot be accessed. #35552

Closed
zhangfannie opened this issue Nov 13, 2019 · 10 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@zhangfannie
Copy link
Contributor

In the initial process, go runtime(runtime.rt0_go()) calls _cgo_init() when using cgo, the x_cgo_init() extends g0.stack which causes g0.stack.lo cannot be accessed.

@zhangfannie
Copy link
Contributor Author

Please refer to the following debug information.
hello.go
package main
import "fmt"

import "C"

func main() {
fmt.Printf("Hello World")
}

go build hello.go
gdb ./hello
(gdb) b gcc_linux_arm64.c:88
Breakpoint 1 at 0x48bb6c: file gcc_linux_arm64.c, line 88.
(gdb) r
Starting program: /home/fanzha02/backup/testcase/testcodes/hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, x_cgo_init (g=0x569cc0 <runtime.g0>, setg=, tlsg=0x0, tlsbase=0xffffb7ff8700) at gcc_linux_arm64.c:88
88 pthread_attr_getstacksize(attr, &size);
(gdb) i r x28
x28 0x569cc0 5676224
(gdb) p/x 'runtime.g0'.stack
$1 = {lo = 0xfffffffde310, hi = 0xfffffffee310} // before the adjusting.
(gdb) ni
89 g->stacklo = (uintptr)&size - size + 4096;
(gdb)
90 pthread_attr_destroy(attr);
(gdb) p/x 'runtime.g0'.stack
$3 = {lo = 0xffffff7ef2f0, hi = 0xfffffffee310} // after adjusting.
(gdb) x 0xffffff7ef2f0
0xffffff7ef2f0: Cannot access memory at address 0xffffff7ef2f0 // Now, the g0.stack.lo is not accessible.
(gdb) info proc mappings
process 9624
Mapped address spaces:

      Start Addr           End Addr       Size     Offset objfile
        0x400000           0x544000   0x144000        0x0 /home/fanzha02/backup/testcase/testcodes/hello
        0x553000           0x554000     0x1000   0x143000 /home/fanzha02/backup/testcase/testcodes/hello
        0x554000           0x56a000    0x16000   0x144000 /home/fanzha02/backup/testcase/testcodes/hello
        0x56a000           0x5a7000    0x3d000        0x0 [heap]
  0xffffb7e37000     0xffffb7f77000   0x140000        0x0 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f77000     0xffffb7f86000     0xf000   0x140000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f86000     0xffffb7f8a000     0x4000   0x13f000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8a000     0xffffb7f8c000     0x2000   0x143000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8c000     0xffffb7f90000     0x4000        0x0
  0xffffb7f90000     0xffffb7fa7000    0x17000        0x0 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fa7000     0xffffb7fb6000     0xf000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb6000     0xffffb7fb7000     0x1000    0x16000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb7000     0xffffb7fb8000     0x1000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb8000     0xffffb7fbc000     0x4000        0x0
  0xffffb7fd2000     0xffffb7fef000    0x1d000        0x0 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7ff8000     0xffffb7ffc000     0x4000        0x0
  0xffffb7ffc000     0xffffb7ffd000     0x1000        0x0 [vvar]
  0xffffb7ffd000     0xffffb7ffe000     0x1000        0x0 [vdso]
  0xffffb7ffe000     0xffffb7fff000     0x1000    0x1c000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7fff000     0xffffb8001000     0x2000    0x1d000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xfffffffce000    0x1000000000000    0x32000        0x0 [stack]

@zhangfannie
Copy link
Contributor Author

I also found that this would cause gsignal.stack.lo to be unreachable. Because adjustSignalStack() will set the gsignal stack of the current m to the g0 stack if the signal is delivered on the g0 stack.

@zhangfannie
Copy link
Contributor Author

CC @cherrymui

@ianlancetaylor
Copy link
Contributor

I feel like you've skipped a few steps.

Does this only happens on linux-arm64?

Are you saying that pthread_attr_getstacksize sets size to the wrong value? Your debugger output doesn't seem to show the value of size.

@ianlancetaylor
Copy link
Contributor

Also, what actually goes wrong?

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 13, 2019
@cherrymui
Copy link
Member

As far as I can tell, nothing goes wrong.

Some background: @zhangfannie and I had some conversation in email about why writing to gsignal.stack.lo failed before CL https://go-review.googlesource.com/c/go/+/204519.

@ianlancetaylor ianlancetaylor added this to the Backlog milestone Nov 13, 2019
@zhangfannie
Copy link
Contributor Author

zhangfannie commented Nov 14, 2019

@ianlancetaylor Please refer to for additional details. And the behavior of x86 is the same. Thank you.
Loading Go Runtime support.
(gdb) b gcc_linux_arm64.c:89
Breakpoint 1 at 0x48bb78: file gcc_linux_arm64.c, line 89.
(gdb) r
Starting program: /home/fanzha02/backup/testcase/testcodes/hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Breakpoint 1, x_cgo_init (g=0x569cc0 <runtime.g0>, setg=, tlsg=0x0, tlsbase=0xffffb7ff8700) at gcc_linux_arm64.c:89
89 g->stacklo = (uintptr)&size - size + 4096;
(gdb) p/x 'runtime.g0'.stack
$3 = {lo = 0xfffffffde310, hi = 0xfffffffee310}
(gdb) p/x size
$1 = 0x800000
(gdb) p/x &size
$2 = 0xfffffffee2f0
(gdb) info proc mappings
process 9890
Mapped address spaces:

      Start Addr           End Addr       Size     Offset objfile
        0x400000           0x544000   0x144000        0x0 /home/fanzha02/backup/testcase/testcodes/hello
        0x553000           0x554000     0x1000   0x143000 /home/fanzha02/backup/testcase/testcodes/hello
        0x554000           0x56a000    0x16000   0x144000 /home/fanzha02/backup/testcase/testcodes/hello
        0x56a000           0x5a7000    0x3d000        0x0 [heap]
  0xffffb7e37000     0xffffb7f77000   0x140000        0x0 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f77000     0xffffb7f86000     0xf000   0x140000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f86000     0xffffb7f8a000     0x4000   0x13f000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8a000     0xffffb7f8c000     0x2000   0x143000 /lib/aarch64-linux-gnu/libc-2.27.so
  0xffffb7f8c000     0xffffb7f90000     0x4000        0x0
  0xffffb7f90000     0xffffb7fa7000    0x17000        0x0 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fa7000     0xffffb7fb6000     0xf000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb6000     0xffffb7fb7000     0x1000    0x16000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb7000     0xffffb7fb8000     0x1000    0x17000 /lib/aarch64-linux-gnu/libpthread-2.27.so
  0xffffb7fb8000     0xffffb7fbc000     0x4000        0x0
  0xffffb7fd2000     0xffffb7fef000    0x1d000        0x0 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7ff8000     0xffffb7ffc000     0x4000        0x0
  0xffffb7ffc000     0xffffb7ffd000     0x1000        0x0 [vvar]
  0xffffb7ffd000     0xffffb7ffe000     0x1000        0x0 [vdso]
  0xffffb7ffe000     0xffffb7fff000     0x1000    0x1c000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xffffb7fff000     0xffffb8001000     0x2000    0x1d000 /lib/aarch64-linux-gnu/ld-2.27.so
  0xfffffffce000    0x1000000000000    0x32000        0x0 [stack]

(gdb)
90 pthread_attr_destroy(attr);
(gdb) p/x 0xfffffffee2f0-size+4096
$7 = 0xffffff7ef2f0
(gdb) p/x 'runtime.g0'.stack
$5 = {lo = 0xffffff7ef2f0, hi = 0xfffffffee310}
(gdb) x 0xffffff7ef2f0
0xffffff7ef2f0: Cannot access memory at address 0xffffff7ef2f0

@ianlancetaylor
Copy link
Contributor

Thanks. Perhaps the issue is that the default stack grows as needed. Or perhaps the thread default stack size simply isn't applicable to the main thread.

Any idea how we can determine the size of the stack here? I suppose we could always just guess. I'm not sure it matters much.

@zhangfannie
Copy link
Contributor Author

@cherrymui Thanks for providing the background.
No errors have occurred so far. I just don't know if this behavior is correct and whether it will cause any potential issues, so I post it for discussion.

@cherrymui
Copy link
Member

Looks like a dup of #26061.

@golang golang locked and limited conversation to collaborators Nov 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants