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
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.
-
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
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
>
>
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo