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

cmd/gc: can't differentiate between different return statements in a function that uses defer #5345

Closed
gopherbot opened this issue Apr 24, 2013 · 4 comments

Comments

@gopherbot
Copy link

by steve.wangbin:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
My program is too large to post here. the relavent function is below:
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: }

This function returned at line 68 and caused a panic, but the stack trace told me that
the line number where the function returns is 61.

What is the expected output?
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:69 +0xf4

What do you see instead?
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

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
windows7 64bit

Which version are you using?  (run 'go version')
go 1.0.3

Please provide any additional information below.
@davecheney
Copy link
Contributor

Comment 1:

Issue #5346 has been merged into this issue.

@gopherbot
Copy link
Author

Comment 2 by steve.wangbin:

fix a typo:
This function returned at line 69 and caused a panic, but the stack trace told me that
the line number where the function returns is 61.

@minux
Copy link
Member

minux commented Apr 24, 2013

Comment 3:

currently, every return in a function that uses defer will do this for each return
statement:
    // assigns return value
    jmp _return
and then near the end of the function:
_return:
    call runtime·deferreturn
    ret
so in deferred functions, you can't differentiate between different return statements.
because the _return label happens to be associated with the first return statement,
in the stack trace, you will see the deferred function is always called from the first
return statement.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 4:

The line number at tip is now the closing } for the function.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants