Re: [go-nuts] goroutine 17 [syscall, 214 minutes, locked to thread]

[jianzhangbjz]

I think I encounter the same issue,  the logs as the following. As 
the https://github.com/golang/go/issues/17384 shows, the issue maybe cased 
by calling deference a NULL pointer at PC 0x3fff801b72c0,I should use the 
debugger to find the function at this address. But, I could not get the 
detailed C code. So, have other ways to solve it? Thanks very much. 

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x2020202020202030 
pc=0x3fff801b72c0]

runtime stack:
runtime.throw(0x11b72955, 0x2a)
/usr/local/go/src/runtime/panic.go:596 +0x7c
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:274 +0x294

goroutine 388 [syscall, locked to thread]:
runtime.cgocall(0x1166ef50, 0xc4209a5338, 0x3fff40035db0)
/usr/local/go/src/runtime/cgocall.go:131 +0xb0 fp=0xc4209a52b8 
sp=0xc4209a5268
k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule._Cfunc_my_bsagomodule_placepatternsimple(0x3fff80214d50,
 
0x3fff48c0, 0xc420a96290, 0x4003e8, 0x2, 0x3fff40035e30, 
0x3fff40035eb0, 0x0)
k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule/_obj/_cgo_gotypes.go:214
 
+0x44 fp=0xc4209a5318 sp=0xc4209a52b8
k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule.(*BsaGomodule).Placepattern.func4(0x3fff80214d50,
 
0x3fff48c0, 0xc420a96290, 0x4003e8, 0xc40002, 0x3fff40035e30, 
0x3fff40035eb0, 0x1)
/root/go-work/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule/bsamodule.go:253
 
+0x134 fp=0xc4209a5388 sp=0xc4209a5318
k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule.(*BsaGomodule).Placepattern(0xc4203dd180,
 
0xc42054a4e0, 0xd, 0x3e8, 0x40, 0x2, 0x0, 0x0, 0x0, 0x0)
/root/go-work/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule/bsamodule.go:253
 
+0x19c fp=0xc4209a54d8 sp=0xc4209a5388
k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule.(*Bsa).PlacePattern(0xc4203dd180,
 
0xc4207bbc00, 0x1, 0x1)
/root/go-work/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/plugin/pkg/scheduler/algorithm/priorities/bsamodule/bsamodule.go:492
 
+0x2c4 fp=0xc4209a5648 sp=0xc4209a54d8
k8s.io/kubernetes/plugin/pkg/scheduler/core.(*genericScheduler).Schedule(0xc4203002d0,
 
0xc4207bbc00, 0x12a77a40, 0xc4207cfc20, 0x0, 0x0, 0x0, 0x0)
/root/go-work/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/plugin/pkg/scheduler/core/generic_scheduler.go:191
 
+0xdcc fp=0xc4209a5a80 sp=0xc4209a5648
k8s.io/kubernetes/plugin/pkg/scheduler.(*Scheduler).schedule(0xc420558048, 
0xc4207bbc00, 0x12af5d20, 0xc420898d70, 0x2, 0x2)



在 2016年8月16日星期二 UTC+8上午9:45:02，Lime Shi写道：
>
> And which bulitin package will call cgo or runtime.LockOSThread. In my 
> project, I used packages net, io, sync.
>
> 在 2016年8月16日星期二 UTC+8上午1:15:29，Ian Lance Taylor写道：
>>
>> On Mon, Aug 15, 2016 at 1:21 AM,   wrote: 
>> > 
>> > In goroutine stack dump there is a dead lock. 
>> > 
>> > goroutine 17 [syscall, 214 minutes, locked to thread]: 
>> > runtime.goexit() 
>> > /root/go/src/runtime/asm_amd64.s:1998 +0x1 
>> > 
>> > 
>> > No more information, just this. I don't know how to debug it. Somebody 
>> can 
>> > help me? 
>>
>> That is not a deadlock, at least not a deadlock in the Go program.  It 
>> is normal for a goroutine to be locked to a thread.  It can happen 
>> because of cgo, or because the code called runtime.LockOSThread.  It 
>> is not a problem.  The problem is that the thread has not made any 
>> progress for 214 minutes; what that is depends on what it is doing. 
>>
>> If this is repeatable, can you get a stack trace with the environment 
>> variable GOTRACEBACK=system ? 
>>
>> Ian 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] goroutine 17 [syscall, 214 minutes, locked to thread]

[Lime Shi]

And which bulitin package will call cgo or runtime.LockOSThread. In my 
project, I used packages net, io, sync.

在 2016年8月16日星期二 UTC+8上午1:15:29，Ian Lance Taylor写道：
>
> On Mon, Aug 15, 2016 at 1:21 AM,   
> wrote: 
> > 
> > In goroutine stack dump there is a dead lock. 
> > 
> > goroutine 17 [syscall, 214 minutes, locked to thread]: 
> > runtime.goexit() 
> > /root/go/src/runtime/asm_amd64.s:1998 +0x1 
> > 
> > 
> > No more information, just this. I don't know how to debug it. Somebody 
> can 
> > help me? 
>
> That is not a deadlock, at least not a deadlock in the Go program.  It 
> is normal for a goroutine to be locked to a thread.  It can happen 
> because of cgo, or because the code called runtime.LockOSThread.  It 
> is not a problem.  The problem is that the thread has not made any 
> progress for 214 minutes; what that is depends on what it is doing. 
>
> If this is repeatable, can you get a stack trace with the environment 
> variable GOTRACEBACK=system ? 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] goroutine 17 [syscall, 214 minutes, locked to thread]

[Ian Lance Taylor]

On Mon, Aug 15, 2016 at 1:21 AM,   wrote:
>
> In goroutine stack dump there is a dead lock.
>
> goroutine 17 [syscall, 214 minutes, locked to thread]:
> runtime.goexit()
> /root/go/src/runtime/asm_amd64.s:1998 +0x1
>
>
> No more information, just this. I don't know how to debug it. Somebody can
> help me?

That is not a deadlock, at least not a deadlock in the Go program.  It
is normal for a goroutine to be locked to a thread.  It can happen
because of cgo, or because the code called runtime.LockOSThread.  It
is not a problem.  The problem is that the thread has not made any
progress for 214 minutes; what that is depends on what it is doing.

If this is repeatable, can you get a stack trace with the environment
variable GOTRACEBACK=system ?

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] goroutine 17 [syscall, 214 minutes, locked to thread]

[lime . syh]

Hi, 

In goroutine stack dump there is a dead lock. 

goroutine 17 [syscall, 214 minutes, locked to thread]:
runtime.goexit()
/root/go/src/runtime/asm_amd64.s:1998 +0x1


No more information, just this. I don't know how to debug it. Somebody can 
help me?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.