go get failing due to cached program

[Joshua]

I'm getting the following error when I run a "go get" from a program I created using "go run". How do I clear it out? The filesimulator.go doesn't exist anymore.

# cd .; hg clone -U https://code.google.com/p/go-uuid D:\repos\heka-build\src\code.google.com\p\go-uuid

panic: open myconfig.toml: The system cannot find the file specified.

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

[signal 0xc0000005 code=0x0 addr=0x0 pc=0x43e5af]

goroutine 1 [running]:

os.(*File).Close(0x0, 0xd, 0x0)

        D:/go/src/pkg/os/file_windows.go:156 +0x1f

main.main()

        D:/repos/gofile/cmd/filesimulator.go:17 +0xb8

[Dave Cheney]

Can you please post the source to this program? FYI go run does not cache any output, it always compiles anew. 

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

[Joshua]

That is the point. The program no longer exists in that location, but the go get is failing pointing to the old file.

Joshua

[Joshua]

Here is the source...

package main

import (

"fmt"

yaml "github.com/gonuts/yaml"

"io/ioutil"

"os"

)

type Config struct {

Name string

}

func main() {

file, err := os.Open("myconfig.yml")

defer file.Close()

if err != nil {

panic(err)

}

d, err := ioutil.ReadAll(file)

if err != nil {

panic(err)

}

var conf Config

err = yaml.Unmarshal(d, &conf)

if err != nil {

panic(err)

}

fmt.Printf("Hello %s!", conf.Name)

}

[Dave Cheney]

I'm really confused, you keep saying go get, but that doesn't run a program, just fetches and (optionally) compile its source. 

go run will run the program you posted below, but it compiles it in a temporary directory and runs it from there. As your os.Open is using a relative path, that would explain why your program is panicking.

[Joshua]

Ah, its not the go-get failing directly. It looks like it may be something specific in the heka build process.

Joshua

[minux]

On Thursday, June 13, 2013, Joshua wrote:

Here is the source...

package main

import (

"fmt"

yaml "github.com/gonuts/yaml"

"io/ioutil"

"os"

)

type Config struct {

Name string

}

func main() {

file, err := os.Open("myconfig.yml")

defer file.Close()

it should not close the file when err != nil, please move the

defer after the following if.

also, using panic for error handling isn't idiomatic Go style. 

[Joshua]

Understood, it was just a test program. It is being cached somewhere and causing a problem when I try to build heka.

Joshua

[minux]

On Thursday, June 13, 2013, Joshua wrote:

Understood, it was just a test program. It is being cached somewhere and causing a problem when I try to build heka.

the defer problem is precisely the cause of the panic in the OP. 

[Joshua]

Correct, but the program no longer exists, so why is the build failing?

Joshua

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Joshua]

I was able to run the go get directly and have it fail:

D:\repos\heka-build\release>d:\go\bin\go.exe get code.google.com/p/go-uuid/uuid

# cd .; hg clone -U https://code.google.com/p/go-uuid D:\repos\heka-build\src\code.google.com\p\go-uuid

panic: open myconfig.toml: The system cannot find the file specified.

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

[signal 0xc0000005 code=0x0 addr=0x0 pc=0x43e5af]

goroutine 1 [running]:

os.(*File).Close(0x0, 0xd, 0x0)

        D:/go/src/pkg/os/file_windows.go:156 +0x1f

main.main()

        D:/repos/gofile/cmd/filesimulator.go:17 +0xb8

goroutine 2 [runnable]:

package code.google.com/p/go-uuid/uuid: exit status 2

[minux]

On Thu, Jun 13, 2013 at 1:48 AM, Joshua <jha...@gmail.com> wrote:

I was able to run the go get directly and have it fail:

what does 

go get -x code.google.com/p/go-uuid/uuid

say?

[Joshua]

Here is the output. Note, this doesn't fail when I use a git repo.

Joshua

D:\repos\heka-build\release>go get -x code.google.com/p/go-uuid/uuid

cd D:\repos\heka-build\src\code.google.com\p\go-uuid

hg pull

# cd D:\repos\heka-build\src\code.google.com\p\go-uuid; hg pull

panic: open myconfig.toml: The system cannot find the file specified.

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

[signal 0xc0000005 code=0x0 addr=0x0 pc=0x43e5af]

goroutine 1 [running]:

os.(*File).Close(0x0, 0xd, 0x0)

        D:/go/src/pkg/os/file_windows.go:156 +0x1f

main.main()

        D:/repos/gofile/cmd/filesimulator.go:17 +0xb8

goroutine 2 [runnable]:

package code.google.com/p/go-uuid/uuid: exit status 2

[minux]

On Thu, Jun 13, 2013 at 2:10 AM, Joshua <jha...@gmail.com> wrote:

Here is the output. Note, this doesn't fail when I use a git repo.

what if you run:

hg version

directly? I suspect you somehow named your program hg.exe. 

[Joshua]

Note, I was able to run the hg clone directly which is why the output is now doing a 'hg pull'

Joshua

D:\repos\heka-build\release>hg version

Mercurial Distributed SCM (version 2.2.1)

(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2012 Matt Mackall and others

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[minux]

On Thu, Jun 13, 2013 at 2:15 AM, Joshua <jha...@gmail.com> wrote:

Note, I was able to run the hg clone directly which is why the output is now doing a 'hg pull'

I'm pretty confused now. You probably have put the binary of filesimulator.go

somewhere, and somehow the go tools invokes it (as hg?).

[Joshua]

I only ran the binary using `go run` so why would it create a binary called hg.exe? Its a very puzzling issue.

Joshua

[Tamás Gulácsi]

Source refers to myconfig.yml, panic says myconfig.toml. Who lies?

[Joshua]

SUCCESS! I ran SysInternals Process Monitor to figure out that go had created a cmd.exe since the file was located in a cmd directory. When go get calls mercurial, it runs cmd /c hg... I must have run `go install` to create the cmd.exe.

Joshua

P.S. the toml vs yaml was because the old version used toml and the new one used yaml. That was the only difference.

[Dave Cheney]

As I understand it if you have this in your $GOPATH

$GOPATH/src/cmd/main.go

go install cmd

will create a cmd.exe which takes precedence over the system cmd.exe.

Can you please paste the output of

echo %PATH%

^ guess, I don't use windows.

[Joshua]

yes, that is what happened. Once I removed the bad cmd.exe, the problem was solved. Thanks for the help.

Joshua

[speter]

While it's best to avoid creating executables called "cmd" on Windows, I believe issues like this could be prevented by changing go get to invoke "%Comspec%" instead of "cmd". If this sounds reasonable, I'm glad to prepare a CL.

Peter

[Dave Cheney]

SGTM. cmd is already a sort if reserved word (might be fixed in 1.1) so your suggestion is preferable to making commands called 'cmd' outlawed. 

[Dave Cheney]

If you could also raise an issue describing the problem that would be most appreciated. 

On 14/06/2013, at 13:27, speter <spete...@gmail.com> wrote:

[Dave Cheney]

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