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.
-
the failure rate is high enough to be motivating. :-) i now have go 1.9
working for
production builds. i will report back with results as soon as i have them.
- erik
On Monday, December 4, 2017 at 6:16:29 PM UTC-8, Ian Lance Taylor wrote:
>
> On Sun, Dec 3, 2017 at 6:42 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?
- erik
On Monday, December 4, 2017 at 2:58:22 AM UTC-8, Peter Walle
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
> debugging this?
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
