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.

Sign up for GitHub

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

Jump to bottom

net/url: silent Segmentation fault. #51140

Closed
genshen opened this issue Feb 11, 2022 · 2 comments
Closed

net/url: silent Segmentation fault. #51140

genshen opened this issue Feb 11, 2022 · 2 comments
Labels
FrozenDueToAge Unfortunate

Comments

@genshen
Copy link

genshen commented Feb 11, 2022

What version of Go are you using (go version)?

$ go version
go version go1.17.7 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/genshen/Library/Caches/go-build"
GOENV="/Users/genshen/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/genshen/Documents/workspace/Golang/GOPATH/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/genshen/Documents/workspace/Golang/GOPATH"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/genshen/.local/develop/go/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/genshen/.local/develop/go/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17.7"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/j1/142yfh3s2x7fv38jf8ncld6m0000gn/T/go-build2394676782=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

// main.go
package main

import "C"
import (
	"fmt"
	"net/url"
)

type S struct {
I int
J int
}
func (s *S) String() {
	fmt.Println("S");
}
func main() {
	var s *S = nil;
	fmt.Println(s);

	var Url     *url.URL = nil;
	fmt.Println(Url)
}

Everything looks fine:

$ go build main.go -o main
$ ./main
<nil>
<nil>

However, under lldb/gdb, there is a crash of EXC_BAD_ACCESS (code=1, address=0x8) on mac (or Segmentation fault on Linux):

$ go build main.go -o main
$ lldb main
(lldb) target create "main"
Current executable set to '/Users/xxx/main' (x86_64).
(lldb) r
Process 3973 launched: '/Users/xxx/main' (x86_64)
<nil>
Process 3973 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
    frame #0: 0x000000000408eaa0 main`net/url.(*URL).String + 64
main`net/url.(*URL).String:
->  0x408eaa0 <+64>: movq   0x8(%rax), %rcx
    0x408eaa4 <+68>: movq   (%rax), %rbx
    0x408eaa7 <+71>: testq  %rcx, %rcx
    0x408eaaa <+74>: je     0x408ebf5                 ; <+405>
Target 0: (main) stopped.
(lldb)

What did you expect to see?

Without EXC_BAD_ACCESS or Segmentation fault error under lldb/gdb. Or give a panic error in normal running (without lldb/gdb).

What did you see instead?

EXC_BAD_ACCESS(mac) or Segmentation fault (linux) error under gdb/lldb (see above).
Please note: It seams fine in normal running (without lldb/gdb), but the error is silent which is hard to find and track it.
Background:
In my development, I call a go api in my swift code, but my app gives me an error of EXC_BAD_ACCESS and the whole app crashed. I spend a lot of time to find the possible bug, and eventually find it may be a bug of the go code (the go code is similar to above main.go code) and created this issue.

related issue: #42816
@bcmills
Copy link
Contributor

bcmills commented Feb 11, 2022

under lldb/gdb, there is a crash of EXC_BAD_ACCESS (code=1, address=0x8) on mac (or Segmentation fault on Linux)

That sounds like a problem with your debugger configuration: namely, it sounds like the debugger is assuming that a segmentation fault necessarily leads to a crash.

That assumption does not hold in Go. A segmentation fault arising from dereferencing a nil pointer is caught by the runtime and transformed into a panic. In Go, panic is a defined control-flow mechanism: it can be stopped with a recover, which is exactly what the fmt package does:
https://cs.opensource.google/go/go/+/master:src/fmt/print.go;l=536-568;drc=2580d0e08d5e9f979b943758d3c49877fb2324cb

(The recover in the fmt package might be a little too aggressive — see #28150 — but it certainly can't be removed at this point without breaking compatibility.)

@bcmills bcmills closed this as completed Feb 11, 2022
@bcmills
Copy link
Contributor

bcmills commented Feb 11, 2022

In my development, I call a go api in my swift code, but my app gives me an error of EXC_BAD_ACCESS and the whole app crashed.

In that case, you might need to raise an issue with the maintainers of the Swift runtime. In my experience, many language runtimes do not properly forward unhandled signals to other runtimes' existing signal handlers. (I'm happy to give further detail on what I've learned about how to robustly forward a signal; feel free to loop me in on any Swift issue you file for this.)

@golang golang locked and limited conversation to collaborators Feb 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Unfortunate
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bcmills @gopherbot @genshen