FAQ
i have simple C wrapper which fetches decodes messages from network and
pushes them to channel. On the other side of the channel I try to decode
messages by using blocking

for{
  decode(<-channel)
}

After few hundred messages received sending goroutine is stuck on pushing
into channel. If I call len(channel) it will be 833362403968, in normal
cases it is 0. Same issue for buffered or unburreded channels.

go version go1.3.3 linux/amd64

i will try to upgrade to 1.4, but curious how len could be more then
allocated cap and why? btw, cap(channel) in this case is 833362485264

PC=0x432051

goroutine 0 [idle]:
runtime.futex(0xb4dab0, 0x0, 0x0, 0x0)
         /usr/lib/golang/src/pkg/runtime/sys_linux_amd64.s:268 +0x21
runtime.futexsleep(0xb4dab0, 0x0, 0xffffffffffffffff)
         /usr/lib/golang/src/pkg/runtime/os_linux.c:49 +0x47
runtime.notesleep(0xb4dab0)
         /usr/lib/golang/src/pkg/runtime/lock_futex.c:135 +0x86
stopm()
         /usr/lib/golang/src/pkg/runtime/proc.c:954 +0xe0
findrunnable()
         /usr/lib/golang/src/pkg/runtime/proc.c:1262 +0x445
schedule()
         /usr/lib/golang/src/pkg/runtime/proc.c:1345 +0xe3
exitsyscall0(0xc20808aea0)
         /usr/lib/golang/src/pkg/runtime/proc.c:1710 +0xdb
runtime.mcall(0x42f207)
         /usr/lib/golang/src/pkg/runtime/asm_amd64.s:181 +0x4b

goroutine 16 [semacquire]:
sync.runtime_Semacquire(0xc20866607c)
         /usr/lib/golang/src/pkg/runtime/sema.goc:199 +0x30
sync.(*WaitGroup).Wait(0xc208665da0)
         /usr/lib/golang/src/pkg/sync/waitgroup.go:129 +0x14b
main.WaitForCtrlC()
         main.go:218 +0x129
main.main()
         main.go:226 +0x67

goroutine 19 [finalizer wait]:
runtime.park(0x418b10, 0xb4b378, 0xb38149)
         /usr/lib/golang/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0xb4b378, 0xb38149)
         /usr/lib/golang/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
         /usr/lib/golang/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
         /usr/lib/golang/src/pkg/runtime/proc.c:1445

goroutine 20 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0xb4ce20)
         go/src/github.com/golang/glog/glog.go:879 +0x75
created by github.com/golang/glog.init·1
         go/src/github.com/golang/glog/glog.go:410 +0x2b2

goroutine 17 [running]:
         goroutine running on other thread; stack unavailable

goroutine 22 [syscall]:
os/signal.loop()
         /usr/lib/golang/src/pkg/os/signal/signal_unix.go:21 +0x1e
created by os/signal.init·1
         /usr/lib/golang/src/pkg/os/signal/signal_unix.go:27 +0x32

goroutine 23 [chan receive]:
database/sql.(*DB).connectionOpener(0xc208046200)
         /usr/lib/golang/src/pkg/database/sql/sql.go:583 +0x48
created by database/sql.Open
         /usr/lib/golang/src/pkg/database/sql/sql.go:442 +0x27c

goroutine 24 [IO wait]:
net.runtime_pollWait(0x7f452e447aa0, 0x72, 0x0)
         /usr/lib/golang/src/pkg/runtime/netpoll.goc:146 +0x66
net.(*pollDesc).Wait(0xc208028300, 0x72, 0x0, 0x0)
         /usr/lib/golang/src/pkg/net/fd_poll_runtime.go:84 +0x46
net.(*pollDesc).WaitRead(0xc208028300, 0x0, 0x0)
         /usr/lib/golang/src/pkg/net/fd_poll_runtime.go:89 +0x42
net.(*netFD).Read(0xc2080282a0, 0xc20807c000, 0x1000, 0x1000, 0x0,
0x7f452e446428, 0xb)
         /usr/lib/golang/src/pkg/net/fd_unix.go:242 +0x34c
net.(*conn).Read(0xc208032068, 0xc20807c000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
         /usr/lib/golang/src/pkg/net/net.go:122 +0xe7
bufio.(*Reader).fill(0xc208004420)
         /usr/lib/golang/src/pkg/bufio/bufio.go:97 +0x1b3
bufio.(*Reader).Read(0xc208004420, 0xc208666058, 0x8, 0x8, 0x8, 0x0, 0x0)
         /usr/lib/golang/src/pkg/bufio/bufio.go:175 +0x230
io.ReadAtLeast(0x7f452e447cb8, 0xc208004420, 0xc208666058, 0x8, 0x8, 0x8,
0x0, 0x0, 0x0)
         /usr/lib/golang/src/pkg/io/io.go:289 +0xf7
io.ReadFull(0x7f452e447cb8, 0xc208004420, 0xc208666058, 0x8, 0x8, 0x8, 0x0,
0x0)
         /usr/lib/golang/src/pkg/io/io.go:307 +0x71
encoding/binary.Read(0x7f452e447cb8, 0xc208004420, 0x7f452e447c60, 0x0,
0x6fefa0, 0xc208666028, 0x0, 0x0)
         /usr/lib/golang/src/pkg/encoding/binary/binary.go:216 +0x1353
bitbucket.org/svidyuk/kdbgo.Decode(0xc208004420, 0x1, 0xc208665cc0, 0x0,
0x0)
         go/src/bitbucket.org/svidyuk/kdbgo/decode.go:128 +0x11f
bitbucket.org/svidyuk/kdbgo.(*KDBConn).ReadMessage(0xc20804e280, 0x773610,
0x6, 0x0, 0x0)
         go/src/bitbucket.org/svidyuk/kdbgo/kdb.go:100 +0x3d
main.func·001()
         main.go:134 +0x68f
created by main.connectKDB
         main.go:160 +0x278

goroutine 25 [chan receive]:
main.func·002()
         main.go:187 +0x10d
created by main.subscribeBBO
         main.go:205 +0x3b7

goroutine 26 [chan receive]:
main.func·003()
         main.go:215 +0x44
created by main.WaitForCtrlC
         main.go:217 +0x119

goroutine 18 [syscall]:
runtime.goexit()
         /usr/lib/golang/src/pkg/runtime/proc.c:1445

rax 0xca
rbx 0xb4cce0
rcx 0xffffffffffffffff
rdx 0x0
rdi 0xb4dab0
rsi 0x0
rbp 0xc208010900
rsp 0x7fff61f73ec8
r8 0x0
r9 0x0
r10 0x0
r11 0x286
r12 0xc2080012fc
r13 0x0
r14 0x0
r15 0x4e84
rip 0x432051
rflags 0x286
cs 0x33
fs 0x0
gs 0x0
exit status 2



--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Tamás Gulácsi at May 6, 2015 at 8:29 pm
    How do you fill that channel from the C side? Data races?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sergey Vidyuk at May 6, 2015 at 9:35 pm
    I am sending messages into channel by copying all data from C to Go
    struct(with GoString, GoBytes). Sometimes other side of the channel just
    blocks forever, while sending side keeps going until len(channel) becomes
    random large number.

    Tried with 1.4.2 - same issue.

    Re data race: should i see it with -race flag?

    Sometimes after few seconds of intensive processing I get panic from GC
    about corrupt pointer
    On Wednesday, 6 May 2015 21:28:57 UTC+1, Tamás Gulácsi wrote:

    How do you fill that channel from the C side? Data races?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrewchamberss at May 6, 2015 at 11:12 pm
    Show code, it seems like you are corrupting something with your C wrapper
    tbh.
    On Thursday, May 7, 2015 at 9:35:02 AM UTC+12, Sergey Vidyuk wrote:

    I am sending messages into channel by copying all data from C to Go
    struct(with GoString, GoBytes). Sometimes other side of the channel just
    blocks forever, while sending side keeps going until len(channel) becomes
    random large number.

    Tried with 1.4.2 - same issue.

    Re data race: should i see it with -race flag?

    Sometimes after few seconds of intensive processing I get panic from GC
    about corrupt pointer
    On Wednesday, 6 May 2015 21:28:57 UTC+1, Tamás Gulácsi wrote:

    How do you fill that channel from the C side? Data races?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sergey Vidyuk at May 7, 2015 at 6:28 am
    Sending side is
    here: https://bitbucket.org/svidyuk/lbmgo/src/a9618e6ee1cd94a5237b12d2a1043408562c8f32/lbm.go?at=master

    Receiving side looks like this:
    var stream chan *lbm.Message
    func subscribe() {
       stream = make(chan *lbm.Message,100)
       go listenStream(stream)
    }

    func listenStream(s chan*lbm.Message) {
        for {
          msg:=<-s
          fmt.Println(msg)
        }
    }



    On Thursday, 7 May 2015 00:12:36 UTC+1, andrewc...@gmail.com wrote:

    Show code, it seems like you are corrupting something with your C wrapper
    tbh.
    On Thursday, May 7, 2015 at 9:35:02 AM UTC+12, Sergey Vidyuk wrote:

    I am sending messages into channel by copying all data from C to Go
    struct(with GoString, GoBytes). Sometimes other side of the channel just
    blocks forever, while sending side keeps going until len(channel) becomes
    random large number.

    Tried with 1.4.2 - same issue.

    Re data race: should i see it with -race flag?

    Sometimes after few seconds of intensive processing I get panic from GC
    about corrupt pointer
    On Wednesday, 6 May 2015 21:28:57 UTC+1, Tamás Gulácsi wrote:

    How do you fill that channel from the C side? Data races?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 6, '15 at 2:03p
activeMay 7, '15 at 6:28a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase