On Wed, Nov 13, 2013 at 7:25 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Tue, Nov 12, 2013 at 8:52 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > >>>> panic: runtime error: invalid memory address or nil pointer dereference >>>> [signal 0xb code=0x1 addr=0x1c] >> >>>> FAIL: runtime/pprof >>>> gmake[2]: *** [runtime/pprof/check] Error 1 >>>> >>>> This one is new, I have to look into it a bit deeper. >>> >>> >>> I don't know what is happening here. I can't recreate it. There was >>> a different problem that could arise in runtime/pprof, that was fixed >>> by a patch I submitted on Saturday >>> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01016.html). So it's >>> possible that this is fixed now. >> >> The failure is specific to !USING_SPLIT_STACK targets: > > The same error triggered on CentOS 5.10 x86_64 (another > !USING_SPLIT_STACK target) for 32bit lib (net, runtime). The panic: > string is the same, only addr=0x9f. There are also a couple of > segfaults (database/sql, net/http) and abort in sync/atomic.
Could you check to see if this patch fixes the problem? Thanks. Ian
diff -r 9b2a1ae08a21 libgo/runtime/proc.c --- a/libgo/runtime/proc.c Thu Nov 14 14:29:49 2013 -0800 +++ b/libgo/runtime/proc.c Thu Nov 14 18:42:54 2013 -0800 @@ -1983,7 +1983,10 @@ #endif gp->gcnext_sp = nil; runtime_memclr(&gp->gcregs, sizeof gp->gcregs); - m->p->syscalltick++; + + // Don't refer to m again, we might be running on a different + // thread after returning from runtime_mcall. + runtime_m()->p->syscalltick++; } static bool