weird call level in stack trace when program crashes

[steve wang]

My program crashed and printed a stack trace where I found that the call level was weird and I mark them with red font below:

panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xc0000005 code=0x1 addr=0x48 pc=0x4700d9]

goroutine 1 [running]:

sync/atomic.CompareAndSwapUint32(0x48, 0x100000000, 0xf800000010, 0x0, 0x428004, ...)

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist767862039/go/src/pkg/sync/atomic/asm_amd64.s:12 +0xd

sync.(*Mutex).Lock(0x48, 0x408a23)

        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist767862039/go/src/pkg/sync/mutex.go:40 +0x38

service/client/gameserver.(*Player).Close(0x0, 0x404949)

        D:/svnroot/service/client/gameserver/player_export.go:81 +0x2d

main._func_002(0x261af0, 0x261ae8, 0xf8400009f0, 0xf840207000)

        D:/svnroot/devtool/robot/case_channelchat.go:65 +0x36

main.(*channelChatCase).prepare(0xf840217600, 0xf84006c0a9, 0x8, 0xf840217620, 0x0, ...)

        D:/svnroot/devtool/robot/case_channelchat.go:61 +0xf4

main.(*channelChatCase).run(0xf840217600, 0xf84009b930, 0xf840084a30, 0x0, 0x0, ...)

        D:/svnroot/devtool/robot/case_channelchat.go:78 +0x96

main.work(0xf84009bb10, 0xf840084a30, 0x0, 0x0, 0xf840051048, ...)

        D:/svnroot/devtool/robot/robot.go:107 +0x103e

main.main()

        D:/svnroot/devtool/robot/robot.go:41 +0x151

And below is the function which throwed the panic:

line 58: func (p *channelChatCase) prepare(account string, pos *position) (player *gameserver.Player, err error) {

line 59: player, err = gameserver.Login(&p.env.Param, account, p.env.Password, "")

line 60: if err != nil {

line 61: return nil, err

line 62: }

line 63: defer func() {

line 64: if err != nil {

line 65: player.Close()

line 66: }

line 67: }()

line 68: if err := player.WaitChannel(p.channeltype); err != nil {

line 69: return nil, err

line 70: }

line 71: if err := player.NewWorld(pos.mapid, pos.x, pos.y); err != nil {

line 72: return nil, err

line 73: }

line 74: return player, nil

line 75: }

As you can see, the defered closure is defined after line 61 where the function return error. It confused me that how this closure could be invoked when the function returned at line 61.  Did I miss some knowledge about Go that I have not known yet?

The running environment:

windows7 64bit

go 1.0.3

[Dmitry Vyukov]

I think the compiler has merged several "return nil, err", so the line
61 is probably the line 69 or 72.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Péter Szilágyi]

Take care because all error returns result in a nil player when the deferred function runs (i.e. lines 69 and 72)

[Dave Cheney]

Peter has the answer. The player variable captured by the defer is the
named return value, not the player value on line 60. Hence it is nil.

All bear witness to the dangers of named returned variables.

[steve wang]

Indeed.

I leant this pitfall before, but I fell into it again. Such an embarrassment.

Thank you guys very much!

[steve wang]

Would this misorder of line number be fixed?

It confused me much.

[steve wang]

Would this misorder of line number be fixed?

It confused me much.

On Wednesday, April 24, 2013 6:14:48 PM UTC+8, Dmitry Vyukov wrote:

[Dmitry Vyukov]

File a bug, then it will be prioritized.

[Albert Strasheim]

Hello

On Wednesday, April 24, 2013 12:38:48 PM UTC+2, Dmitry Vyukov wrote:

File a bug, then it will be prioritized.

I also hit this exact issue a few minutes ago. Very confusing.

Please file an issue if you have a small piece of code that reproduces it.

Cheers

Albert

[steve wang]

It's done here:

https://code.google.com/p/go/issues/detail?id=5345

As I think the problem should be easy to analyse, is it necessary to reproduce it with a small piece of program?

If necessary, I will try later. 

[minux]

On Thu, Apr 25, 2013 at 2:30 AM, steve wang <steve....@gmail.com> wrote:

It's done here:

https://code.google.com/p/go/issues/detail?id=5345

As I think the problem should be easy to analyse, is it necessary to reproduce it with a small piece of program?

If necessary, I will try later. 

i think any function with multiple return statements and deferred function will trigger this

bug.

the cause is easy to find, but the solution is not, IMO.

As this is not super critical for Go 1.1, and a proper solution will involve fixing the

Go compiler, i'm inclined to say we'd better delay it until after Go 1.1.

please place further comment on the issue tracker.