Hi Juan,

Can you please provide some more information. The panic line alone is not that useful by itself, can you please include the entire output, and if possible a code sample that demonstrates the problem.

Hi all,

I am currently trying to reduce the example to the smallest size possible
possible. I have not used either unsafe or cgo packages. As soon as I have
a smaller code that behaves the same I will send it through.

Cheers,

Juan Montenegro

2015-09-14 19:09 GMT+10:00 Minux Ma notifications@github.com:

Does the program use the unsafe package or cgo?

—
Reply to this email directly or view it on GitHub
#12608 (comment).

@jdmontenegro don't forget the initial request to include the full output that you see. That should be something to get us started.

Hi,

This is the final error that appears 3/10 times when running on the same
data:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x18 pc=0x45a23e]

goroutine 17998 [running]:
ContigMapping.(_ContigMap).buildMap(0xc8200a2090, 0x7fb7d962d000)
/home/jdmc/Documents/GOLANG/src/ContigMapping/ContigMapping.go:58
+0x10e
ContigMapping.(_ContigMap).filterContigs(0xc8200a2090, 0x0)
/home/jdmc/Documents/GOLANG/src/ContigMapping/ContigMapping.go:72
+0x4e
ContigMapping.(*ContigMap).WriteMap(0xc8200a2090, 0x0, 0x0)
/home/jdmc/Documents/GOLANG/src/ContigMapping/ContigMapping.go:141
+0x47
main.main.func2(0xc820010410, 0xc8200a2090, 0xc820022240)
/home/jdmc/Documents/GOLANG/src/ContigMapper/main.go:162 +0x30
created by main.main
/home/jdmc/Documents/GOLANG/src/ContigMapper/main.go:167 +0x904

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc82001041c)
/home/jdmc/.gvm/gos/go1.5/src/runtime/sema.go:43 +0x26
sync.(*WaitGroup).Wait(0xc820010410)
/home/jdmc/.gvm/gos/go1.5/src/sync/waitgroup.go:126 +0xb4
main.main()
/home/jdmc/Documents/GOLANG/src/ContigMapper/main.go:169 +0x939

The program uses a library "ContigMapper"that I wrote and then uses
goroutines to run some analysis on several instances of the struct in
parallel. The instances are stored in a map[string]*Ptr_to_struct. Inside
the struct I have defined a field that stores an array with two elements.
The trace points to one line that tries to retrieve the first element in
this field. When compiled with go1.2, all runs finish correctly, when
compiled with go1.4+, it randomly fails with the error above. Most of the
times it finishes correctly.

Cheers,

Juan Montenegro

2015-09-15 10:37 GMT+10:00 Dave Cheney notifications@github.com:

@jdmontenegro https://github.com/jdmontenegro don't forget the initial
request to include the full output that you see. That should be something
to get us started.

—
Reply to this email directly or view it on GitHub
#12608 (comment).

@jdmontenegro thank you for your reply. These crashes are commonly caused by races in your program. Have you run your tests or built a race enable version of your program ?

To run your tests with the race detector

go test -race github.com/you/yourpackage/...

To build a race enable version of your program

go build -race github.com/you/yourpackage/yourcommand

See http://blog.golang.org/race-detector

Thanks for your replies.
It does seem like a race condition. But why would it run correctly when
compiled with go1.2, shouldn't the race condition be true for all
compilations?

Cheers,

Juan Montenegro

2015-09-15 11:01 GMT+10:00 Brad Fitzpatrick notifications@github.com:

See http://blog.golang.org/race-detector

—
Reply to this email directly or view it on GitHub
#12608 (comment).

If your code has a race condition then it's behaviour is considered to be undefined. The fact that it worked without fault previously does not change this fact. Your programs must be free of race conditions or their results are not defined.

I will close this issue now as there is nothing to be done here.

Hi,

What does it mean when running:

go run -race myprogram.go -f file1 -g file2 -out outfile

shows the expected output and no complain. Does that mean there is no data
race? or is it a problem with the race detector that cannot handle programs
that read and write to other files? My program also writes to stderr, could
this be affecting the race detector output?

I run this test to check if the race detector was working correctly:

func main() {
c := make(chan bool)
m := make(map[string]string)
go func() {
m["1"] = "a" // First conflicting access.
c <- true
}()
m["2"] = "b" // Second conflicting access.
<-c
for k, v := range m {
fmt.Println(k, v)
}
}

from here:

https://golang.org/doc/articles/race_detector.html

and the race detector shows the expected error

WARNING: DATA RACE
Write by goroutine 5:
runtime.mapassign1()
/home/juanda/.gvm/gos/go1.4/src/runtime/hashmap.go:376 +0x0
main.func·001()
/home/juanda/Documents/GO/src/race.go:11 +0xa3

Previous write by main goroutine:
runtime.mapassign1()
/home/juanda/.gvm/gos/go1.4/src/runtime/hashmap.go:376 +0x0
main.main()
/home/juanda/Documents/GO/src/race.go:14 +0x22e

Goroutine 5 (running) created at:
main.main()

/home/juanda/Documents/GO/src/race.go:13 +0x1ac

1 a
2 b
Found 1 data race(s)
exit status 66

But with my script there is no output. Does that mean there is no race
in my script?

Best regards,

Juan Montenegro

2015-09-15 12:47 GMT+10:00 Dave Cheney notifications@github.com:

Closed #12608 #12608.

—
Reply to this email directly or view it on GitHub
#12608 (comment).