Re: [go-nuts] corrupt stack?

Does the program use cgo? Matt On Monday, April 2, 2018 at 6:48:14 PM UTC-5, Erik Quanstrom wrote: > > after upgrading to 1.9 (50% reduction) and finding a data race we didn't > see in testing, > we're still hunting down about 1 crash per 67 million hours of runtime. > > needless to say, the

Re: [go-nuts] corrupt stack?

after upgrading to 1.9 (50% reduction) and finding a data race we didn't see in testing, we're still hunting down about 1 crash per 67 million hours of runtime. needless to say, the economical thing to do is to ignore the problem, but it sure bugs (!) me. the correct number of crashes is 0. -

Re: [go-nuts] corrupt stack?

On Sun, Dec 3, 2017 at 6:42 PM, wrote: > > i'm running go 1.8.3 on linux. about 1 in ~10 billion calls (spread across > many machines), i get > a backtrace that looks like the following: > > panic: runtime error: invalid memory address or nil pointer dereference > [signal

Re: [go-nuts] corrupt stack?

Erik, any chance you're hitting this? https://github.com/golang/go/issues/20427 Related article discussing bad ram: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ On Mon, Dec 4, 2017, 5:35 PM 'Keith Randall' via golang-nuts < golang-nuts@googlegroups.com> wrote: > package main > >

Re: [go-nuts] corrupt stack?

package main // Convert an *A to a *B, using a data race. // Works for any types A and B. func cast(a *A) *B { var x interface{} go func() { for i := 0; i < 10; i++ { x = a } }() go func() { var b *B for i := 0; i < 10; i++ { x = b } }() for i := 0; i < 10; i++ { b, ok := x.(*B) if

Re: [go-nuts] corrupt stack?

Programs with a data race can do all kinds of things that seem incredibly improbable to humans, because compilers assume that the program is race-free and make optimizations that are unsafe in the presence of races. See

Re: [go-nuts] corrupt stack?

On Mon, Dec 4, 2017 at 1:57 PM wrote: > i should have mentioned the race detector found nothing. jan, can you give an example of a go program > setting a pointer to -1 without using unsafe? this requires the gc to have free'd something that is still live, > doesn't it? See

Re: [go-nuts] corrupt stack?

i should have mentioned the race detector found nothing. jan, can you give an example of a go program setting a pointer to -1 without using unsafe? this requires the gc to have free'd something that is still live, doesn't it? - erik On Monday, December 4, 2017 at 2:58:22 AM UTC-8, Peter

Re: [go-nuts] corrupt stack?

Some worthwhile reading: https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong Races are important, and if your program has a race, otherwise impossible-seeming things can happen. First ruling out races is a worthwhile activity. In terms of debugging

Re: [go-nuts] corrupt stack?

If course it can. On Mon, Dec 4, 2017, 07:46 wrote: > a program not using unsafe cannot set a pointer to -1, even if there is a > race, right? > > - erik > > > On Sunday, December 3, 2017 at 10:20:44 PM UTC-8, Jan Mercl wrote: > >> On Mon, Dec 4, 2017 at 7:03 AM

Re: [go-nuts] corrupt stack?

a program not using unsafe cannot set a pointer to -1, even if there is a race, right? - erik On Sunday, December 3, 2017 at 10:20:44 PM UTC-8, Jan Mercl wrote: > > On Mon, Dec 4, 2017 at 7:03 AM wrote: > > > does anyone have any idea what's going on here, or some hints on

Re: [go-nuts] corrupt stack?

On Mon, Dec 4, 2017 at 7:03 AM wrote: > does anyone have any idea what's going on here, or some hints on debugging this? What does the race detector say? -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] corrupt stack?

i'm running go 1.8.3 on linux. about 1 in ~10 billion calls (spread across many machines), i get a backtrace that looks like the following: panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x4c3406] goroutine