go-stack / stack Goto Github PK

View Code? Open in Web Editor NEW

394.0 7.0 33.0 1.15 MB

Package stack implements utilities to capture, manipulate, and format call stacks.

License: MIT License

Go 100.00%

go golang stacktrace

stack's People

Contributors

Stargazers

Watchers

stack's Issues

May I ask for a new release tag containing the latest commits?

I am using do gep and this package is a transitive dependency of another one I'm using.

Can't update this package to master :( without doing some micro-management in my deps...

Not critical but thanks!

Possible to get the package name at a given call depth?

Any interest in having that feature in the package?

Debugger stopping at findSigpanic()

when I run the debugger. It keeps breaking on this intentional panic and I don't know how to get my debugger to ignore this.

what the sigpanic is used for ?

Here is the code used in Caller() func:

	c.pc = pcs[1]
	if runtime.FuncForPC(pcs[0]) != sigpanic {
		c.pc--
	}

Could you please explain why the program counter is reduced by one ?

Getting SIGSEGV when debugging with gdb

Hi,

I'm creating a couple of applications and I believe one of the dependencies I'm using depends on this library. It seems that go-stack/stack causes a SIGSEGV error with gdb.

As I was trying to debug one of my applications, I got stuck with this error. I created two gists (gist1 and gist2) to showcase what's happening:

In gist1 I've simply copied and pasted the channels example from golang docs. After compiling the program with go build -gcflags "-N -l" main.go I started gdb with gdb main and was able to use it normally.
In gist2 I've changed the code to include the example in stack README file. Compiled the code go build -gcflags "-N -l" main.go and started gdb. After setting a breakpoint and running the code, gdb shows the error Thread 1 "main" received signal SIGSEGV, Segmentation fault. 0x000000000046c898 in github.com/go-stack/stack.findSigpanic.func1 (p=0x0, &fn=0xc820041f10, ~r0=0) at /opt/gopath/src/github.com/go-stack/stack/stack.go:228

Both versions of this example code are statically linked. stack library is built to master branch (not vendored).

Versions:

$ go version
go version go1.6 linux/amd64

$ gdb -v
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".

Dropping support for older go versions

I see we are supporting a lot of go versions

stack/.github/workflows/test.yml

Line 14 in e5bbd7d

- 1.7.x

I think we can drop support for versions prior to go modules

#25 (comment)

Keeping the above PR in mind we can keep the minimum to go 1.12

Deprecated function Call.PC() breaks tinygo compatibility?

Following a rabbit hole of dependencies that starts at tinygo-org/tinygo#2153, I noticed that

$ git clone https://github.com/go-stack/stack
$ cd stack
$ go test

succeeds, but

$ tinygo test

fails with

stack.go:164:17: c.frame.PC undefined (type runtime.Frame has no field or method PC)

That's

162 // Deprecated: Use Call.Frame instead.
163 func (c Call) PC() uintptr {
164         return c.frame.PC
165 }

So for what it's worth, the deprecated function Call.PC() is causing tinygo build failure. Commenting it out lets tinygo test pass.

Several functions and methods broken when built with `go build -trimpath`

$ go test -trimpath
--- FAIL: TestCallStackString (0.00s)
    stack_test.go:343:
         got []
        want [stack_test.go:362 stack_test.go:335]
--- FAIL: TestCallStackMarshalText (0.00s)
    stack_test.go:357:
         got [91 93]
        want [91 115 116 97 99 107 95 116 101 115 116 46 103 111 58 51 54 50 32 115 116 97 99 107 95 116 101 115 116 46 103 111 58 51 52 56 93]        
--- FAIL: TestTrimRuntime (0.00s)
    stack_test.go:403: got len(trace) == 0, want 1, goroot: "go", trace: []
--- FAIL: TestCallFormat (0.00s)
    stack_test.go:259: fmt.Sprintf("%+s", Call(func)) = github.com/go-stack/stack_test/stack_test.go, want github.com/go-stack/stack/stack_test.go     
    stack_test.go:259: fmt.Sprintf("%+v", Call(func)) = github.com/go-stack/stack_test/stack_test.go:209, want github.com/go-stack/stack/stack_test.go:209
    stack_test.go:259: fmt.Sprintf("%+s", Call(meth)) = github.com/go-stack/stack_test/stack_test.go, want github.com/go-stack/stack/stack_test.go     
    stack_test.go:259: fmt.Sprintf("%+v", Call(meth)) = github.com/go-stack/stack_test/stack_test.go:200, want github.com/go-stack/stack/stack_test.go:200
--- FAIL: Example_callFormat (0.00s)
got:
github.com/go-stack/stack_test/format_test.go
format_test.go:13   Example_callFormat()
want:
github.com/go-stack/stack/format_test.go
format_test.go:13   Example_callFormat()
FAIL
exit status 1
FAIL    github.com/go-stack/stack       0.200s

Include full Apache License text

Hi,

Item 4a of the Apache License 2.0 requires that whoever redistributes the licensed work, does it with a copy of the licence text [1]. Would you be willing to add such text to the repository so whoever is distributing this package does not need to attach a copy of the license to it?

Thanks!

[1] https://www.apache.org/licenses/LICENSE-2.0

Drop recommendation of gopkg.in.

See go-kit/kit#197 for background.

Some consumers of this package are reluctant to use gopkg.in or other third-party import proxies. With the trend toward vendoring in the Go community perhaps all that is needed is good release tags in the repo and let main applications vendor the release they want.

Link to "the docs"

Where are "the docs" mentioned in the last line of the README ?

See the docs for all of the supported formatting options

Allow access to the underlying uintptr and *runtime.Func

Maybe make Call.fn and Call.pc exported (uppercase), or create access methods for them.

If another third-party package makes use of either of those (the stdlib representations of a stack frame), we currently don't have access if the stack was collected with this package.

My specific use-case is that I'm adding sentry error reporing to a project that already uses erroneous (error wrapper that carries a stack trace with it). I want to send the deeper, more accurate stack trace that erroneous collected to Sentry, but it's held as a stack.CallStack, meaning I can't get the uintptr that sentry wants.

Add line source code at each frame of stack?

This library is great. Would be nice to see the actual line's source code at each frame with context lines. Here's an example of one I did on node.js to help my team troubleshoot faster

https://raw.githubusercontent.com/barc/express-error/master/img/stack.png

I sometimes see error line when an error is wrapped.

Evaluate using runtime.CallersFrames internally.

runtime.CallersFrames was added in Go 1.7. Using it could clean up some of the internals of this package and eliminate the need for the findSigpanic function.

go modules not use

The import package path is inconsistent with your go. mod path, which makes it impossible to import the package.

go: gopkg.in/[email protected]: go.mod has non-....v1 module path "github.com/go-stack/stack" at revision v1.8.0

segmentation violation on Ubuntu on Windows

We've received a crash report ethereum/go-ethereum#14777 from one of our users running our project on Ubuntu on Windows. Alas there's no need to do that as we do ship Windows binaries, imho it's still a bug that should be fixed here. It's probably a trivial fix.

Here's the crash report:

unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x5fb5b1]

goroutine 1 [running, locked to thread]:
runtime.throw(0xeac94e, 0x5)
        /usr/lib/go-1.8/src/runtime/panic.go:596 +0x95 fp=0xc42004fce0 sp=0xc42004fcc0
runtime.sigpanic()
        /usr/lib/go-1.8/src/runtime/signal_unix.go:297 +0x28c fp=0xc42004fd30 sp=0xc42004fce0
github.com/ethereum/go-ethereum/vendor/github.com/go-stack/stack.findSigpanic.func1(0x0, 0xc42004fd70, 0x0)
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/vendor/github.com/go-stack/stack/stack.go:228 +0x51 fp=0xc42004fd58 sp=0xc42004fd30
github.com/ethereum/go-ethereum/vendor/github.com/go-stack/stack.findSigpanic(0xee3b63)
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/vendor/github.com/go-stack/stack/stack.go:229 +0x3d fp=0xc42004fd88 sp=0xc42004fd58
github.com/ethereum/go-ethereum/vendor/github.com/go-stack/stack.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/vendor/github.com/go-stack/stack/stack.go:233 +0xa4 fp=0xc42004fdb8 sp=0xc42004fd88
github.com/ethereum/go-ethereum/log.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/log/syslog.go:58 +0x82 fp=0xc42004fdf8 sp=0xc42004fdb8
github.com/ethereum/go-ethereum/trie.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/trie/trie.go:506 +0x7d fp=0xc42004fe38 sp=0xc42004fdf8
github.com/ethereum/go-ethereum/core/types.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/core/types/transaction_signing.go:321 +0x87 fp=0xc42004fe98 sp=0xc42004fe38
github.com/ethereum/go-ethereum.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/interfaces.go:211 +0x5a fp=0xc42004fec8 sp=0xc42004fe98
github.com/ethereum/go-ethereum/accounts.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/accounts/url.go:89 +0x50 fp=0xc42004fef8 sp=0xc42004fec8
main.init()
        /build/ethereum-vg6EjT/ethereum-1.6.6+build10111+trusty/build/_workspace/src/github.com/ethereum/go-ethereum/cmd/geth/usage.go:303 +0x69 fp=0xc42004ff88 sp=0xc42004fef8
runtime.main()
        /usr/lib/go-1.8/src/runtime/proc.go:173 +0x1ca fp=0xc42004ffe0 sp=0xc42004ff88
runtime.goexit()
        /usr/lib/go-1.8/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc42004ffe8 sp=0xc42004ffe0

Btw, I did a quick search to see if anyone else hit this and indeed there are other instances too, such as inconshreveable/ngrok#364

go-stack / stack Goto Github PK

stack's People

Contributors

Stargazers

Watchers

Forkers

stack's Issues

Recommend Projects

Recommend Topics

Recommend Org