net/url: silent Segmentation fault.

[genshen]

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]

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]

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.)