FAQ
Hello,

I was playing with a dummy tool to find my duplicated jpg files in my
iPhoto library and I observed the following problem. It looks like compiled
binary works couple of times before throwing a panic. The problem is
reproducible on my machine (memory issues?). I tried searching the group
archives and open issues at code.google.com/p/go but couldn't find
something related.

This is a go-1.0.3 on top of OSX 10.8.2

[caglar@Zangetsu:~/Projects/github/godup] go build dup.go
[caglar@Zangetsu:~/Projects/github/godup] ./dup
[caglar@Zangetsu:~/Projects/github/godup] ./dup
CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
[caglar@Zangetsu:~/Projects/github/godup] ./dup
CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
[caglar@Zangetsu:~/Projects/github/godup] ./dup
panic: invalid memory address or nil pointer dereference
throw: panic during gc
[signal 0xb code=0x1 addr=0x0 pc=0x9045]

[...]


You can find the whole output at [1], the ugly code at [1] and finally the compiled binary at [3]


[1] http://10ur.org/panic.txt

[2] http://10ur.org/dup.go

[3] http://10ur.org/dup [its md5sum is 905a045cf02f6f4b090daee9742f404e])


--

S.Çağlar Onur <caglar@10ur.org>

--

Search Discussions

  • Dmitry Vyukov at Nov 15, 2012 at 6:00 am

    On Thursday, November 15, 2012 2:20:55 AM UTC+4, S.Çağlar Onur wrote:

    Hello,

    I was playing with a dummy tool to find my duplicated jpg files in my
    iPhoto library and I observed the following problem. It looks like compiled
    binary works couple of times before throwing a panic. The problem is
    reproducible on my machine (memory issues?). I tried searching the group
    archives and open issues at code.google.com/p/go but couldn't find
    something related.

    This is a go-1.0.3 on top of OSX 10.8.2

    [caglar@Zangetsu:~/Projects/github/godup] go build dup.go
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    panic: invalid memory address or nil pointer dereference
    throw: panic during gc
    [signal 0xb code=0x1 addr=0x0 pc=0x9045]
    Hi,

    Is it 32 or 64 bit?
    It looks like http://code.google.com/p/go/issues/detail?id=3798

    --
  • S.Çağlar Onur at Nov 15, 2012 at 7:41 pm
    Hi Dmitry,
    On Thursday, November 15, 2012 1:00:20 AM UTC-5, Dmitry Vyukov wrote:
    On Thursday, November 15, 2012 2:20:55 AM UTC+4, S.Çağlar Onur wrote:

    Hello,

    I was playing with a dummy tool to find my duplicated jpg files in my
    iPhoto library and I observed the following problem. It looks like compiled
    binary works couple of times before throwing a panic. The problem is
    reproducible on my machine (memory issues?). I tried searching the group
    archives and open issues at code.google.com/p/go but couldn't find
    something related.

    This is a go-1.0.3 on top of OSX 10.8.2

    [caglar@Zangetsu:~/Projects/github/godup] go build dup.go
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    panic: invalid memory address or nil pointer dereference
    throw: panic during gc
    [signal 0xb code=0x1 addr=0x0 pc=0x9045]
    Hi,

    Is it 32 or 64 bit?
    It looks like http://code.google.com/p/go/issues/detail?id=3798
    It is 64 bit. If I understand correctly changing map[uint64]string to map[string]string
    should resolve this problem because of uint64's alignment issue, right?

    Best,

    --
  • S.Çağlar Onur at Nov 15, 2012 at 7:48 pm
    Hi,
    On Thursday, November 15, 2012 2:41:54 PM UTC-5, S.Çağlar Onur wrote:

    Hi Dmitry,
    On Thursday, November 15, 2012 1:00:20 AM UTC-5, Dmitry Vyukov wrote:
    On Thursday, November 15, 2012 2:20:55 AM UTC+4, S.Çağlar Onur wrote:

    Hello,

    I was playing with a dummy tool to find my duplicated jpg files in my
    iPhoto library and I observed the following problem. It looks like compiled
    binary works couple of times before throwing a panic. The problem is
    reproducible on my machine (memory issues?). I tried searching the group
    archives and open issues at code.google.com/p/go but couldn't find
    something related.

    This is a go-1.0.3 on top of OSX 10.8.2

    [caglar@Zangetsu:~/Projects/github/godup] go build dup.go
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/github/godup] ./dup
    panic: invalid memory address or nil pointer dereference
    throw: panic during gc
    [signal 0xb code=0x1 addr=0x0 pc=0x9045]
    Hi,

    Is it 32 or 64 bit?
    It looks like http://code.google.com/p/go/issues/detail?id=3798
    It is 64 bit. If I understand correctly changing map[uint64]string to map[string]string
    should resolve this problem because of uint64's alignment issue, right?
    I just tried changing the map but didn't help (unless I made a mistake),
    please see http://10ur.org/panic_2.txt

    Best,

    --
  • Dmitry Vyukov at Nov 15, 2012 at 7:52 pm

    On Thu, Nov 15, 2012 at 11:48 PM, S.Çağlar Onur wrote:

    Hi,

    On Thursday, November 15, 2012 2:41:54 PM UTC-5, S.Çağlar Onur wrote:

    Hi Dmitry,
    On Thursday, November 15, 2012 1:00:20 AM UTC-5, Dmitry Vyukov wrote:
    On Thursday, November 15, 2012 2:20:55 AM UTC+4, S.Çağlar Onur wrote:

    Hello,

    I was playing with a dummy tool to find my duplicated jpg files in my
    iPhoto library and I observed the following problem. It looks like compiled
    binary works couple of times before throwing a panic. The problem is
    reproducible on my machine (memory issues?). I tried searching the group
    archives and open issues at code.google.com/p/go but couldn't find
    something related.

    This is a go-1.0.3 on top of OSX 10.8.2

    [caglar@Zangetsu:~/Projects/**github/godup] go build dup.go
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/**20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/**20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/**20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/**20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    panic: invalid memory address or nil pointer dereference
    throw: panic during gc
    [signal 0xb code=0x1 addr=0x0 pc=0x9045]
    Hi,

    Is it 32 or 64 bit?
    It looks like http://code.google.com/p/go/**issues/detail?id=3798<http://code.google.com/p/go/issues/detail?id=3798>
    It is 64 bit. If I understand correctly changing map[uint64]string to map[string]string
    should resolve this problem because of uint64's alignment issue, right?
    I just tried changing the map but didn't help (unless I made a mistake),
    please see http://10ur.org/panic_2.txt
    Humm... then perhaps you have a data race in the code, that badly corrupts
    memory. If you are on tip, then you may to run under race detector (go
    test/run -race).

    --
  • S.Çağlar Onur at Nov 15, 2012 at 8:54 pm
    Hi Dmitry,

    Thanks for the tip about the tip, I wasn't aware of that race detector. So
    I switched to that (I was using release) and it looks like I've a race due
    to map operations not being atomic.

    [caglar@Zangetsu:~/Projects/github/godup] go run -race dup2.go
    ==================
    WARNING: DATA RACE
    Read by goroutine 3:
    main.hasher()
    /Users/caglar/Projects/github/godup/dup2.go:47 +0x46b

    Previous write by goroutine 2:
    main.hasher()
    /Users/caglar/Projects/github/godup/dup2.go:52 +0x5ff

    Goroutine 3 (running) created at:
    main.main()
    /Users/caglar/Projects/github/godup/dup2.go:67 +0x162
    runtime.main()
    /Users/caglar/Downloads/go/src/pkg/runtime/proc.c:248 +0x91

    Goroutine 2 (finished) created at:
    main.main()
    /Users/caglar/Projects/github/godup/dup2.go:67 +0x162
    runtime.main()
    /Users/caglar/Downloads/go/src/pkg/runtime/proc.c:248 +0x91

    ==================

    Thanks!

    On Thu, Nov 15, 2012 at 2:52 PM, Dmitry Vyukov wrote:

    On Thu, Nov 15, 2012 at 11:48 PM, S.Çağlar Onur wrote:

    Hi,

    On Thursday, November 15, 2012 2:41:54 PM UTC-5, S.Çağlar Onur wrote:

    Hi Dmitry,
    On Thursday, November 15, 2012 1:00:20 AM UTC-5, Dmitry Vyukov wrote:
    On Thursday, November 15, 2012 2:20:55 AM UTC+4, S.Çağlar Onur wrote:

    Hello,

    I was playing with a dummy tool to find my duplicated jpg files in my
    iPhoto library and I observed the following problem. It looks like compiled
    binary works couple of times before throwing a panic. The problem is
    reproducible on my machine (memory issues?). I tried searching the group
    archives and open issues at code.google.com/p/go but couldn't find
    something related.

    This is a go-1.0.3 on top of OSX 10.8.2

    [caglar@Zangetsu:~/Projects/**github/godup] go build dup.go
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/**20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/**20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/**20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/**20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    panic: invalid memory address or nil pointer dereference
    throw: panic during gc
    [signal 0xb code=0x1 addr=0x0 pc=0x9045]
    Hi,

    Is it 32 or 64 bit?
    It looks like http://code.google.com/p/go/**issues/detail?id=3798<http://code.google.com/p/go/issues/detail?id=3798>
    It is 64 bit. If I understand correctly changing map[uint64]string to map[string]string
    should resolve this problem because of uint64's alignment issue, right?
    I just tried changing the map but didn't help (unless I made a mistake),
    please see http://10ur.org/panic_2.txt
    Humm... then perhaps you have a data race in the code, that badly corrupts
    memory. If you are on tip, then you may to run under race detector (go
    test/run -race).

    --
    S.Çağlar Onur <caglar@10ur.org>

    --
  • Dmitry Vyukov at Nov 16, 2012 at 8:22 am

    On Fri, Nov 16, 2012 at 12:54 AM, S.Çağlar Onur wrote:

    Hi Dmitry,

    Thanks for the tip about the tip, I wasn't aware of that race detector. So
    I switched to that (I was using release) and it looks like I've a race due
    to map operations not being atomic.

    [caglar@Zangetsu:~/Projects/github/godup] go run -race dup2.go
    ==================
    WARNING: DATA RACE
    Read by goroutine 3:
    main.hasher()
    /Users/caglar/Projects/github/godup/dup2.go:47 +0x46b

    Previous write by goroutine 2:
    main.hasher()
    /Users/caglar/Projects/github/godup/dup2.go:52 +0x5ff

    Goroutine 3 (running) created at:
    main.main()
    /Users/caglar/Projects/github/godup/dup2.go:67 +0x162
    runtime.main()
    /Users/caglar/Downloads/go/src/pkg/runtime/proc.c:248 +0x91

    Goroutine 2 (finished) created at:
    main.main()
    /Users/caglar/Projects/github/godup/dup2.go:67 +0x162
    runtime.main()
    /Users/caglar/Downloads/go/src/pkg/runtime/proc.c:248 +0x91

    ==================

    Thanks!
    Great!
    Map operations were never intended to be atomic. You need to protect maps
    with channels/mutexes.



    On Thu, Nov 15, 2012 at 2:52 PM, Dmitry Vyukov wrote:

    On Thu, Nov 15, 2012 at 11:48 PM, S.Çağlar Onur wrote:

    Hi,

    On Thursday, November 15, 2012 2:41:54 PM UTC-5, S.Çağlar Onur wrote:

    Hi Dmitry,
    On Thursday, November 15, 2012 1:00:20 AM UTC-5, Dmitry Vyukov wrote:
    On Thursday, November 15, 2012 2:20:55 AM UTC+4, S.Çağlar Onur wrote:

    Hello,

    I was playing with a dummy tool to find my duplicated jpg files in my
    iPhoto library and I observed the following problem. It looks like compiled
    binary works couple of times before throwing a panic. The problem is
    reproducible on my machine (memory issues?). I tried searching the group
    archives and open issues at code.google.com/p/go but couldn't find
    something related.

    This is a go-1.0.3 on top of OSX 10.8.2

    [caglar@Zangetsu:~/Projects/**github/godup] go build dup.go
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/**20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/**20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    CONFLICT between /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/26/**20120926-140126/IMG_0601.JPG and /Users/caglar/Pictures/iPhoto Library/Masters/2012/09/29/**20120929-235343/IMG_0780.JPG
    [caglar@Zangetsu:~/Projects/**github/godup] ./dup
    panic: invalid memory address or nil pointer dereference
    throw: panic during gc
    [signal 0xb code=0x1 addr=0x0 pc=0x9045]
    Hi,

    Is it 32 or 64 bit?
    It looks like http://code.google.com/p/go/**issues/detail?id=3798<http://code.google.com/p/go/issues/detail?id=3798>
    It is 64 bit. If I understand correctly changing map[uint64]string to map[string]string
    should resolve this problem because of uint64's alignment issue, right?
    I just tried changing the map but didn't help (unless I made a mistake),
    please see http://10ur.org/panic_2.txt
    Humm... then perhaps you have a data race in the code, that badly
    corrupts memory. If you are on tip, then you may to run under race detector
    (go test/run -race).

    --
    S.Çağlar Onur <caglar@10ur.org>
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 14, '12 at 11:03p
activeNov 16, '12 at 8:22a
posts7
users2
websitegolang.org

2 users in discussion

S.Çağlar Onur: 4 posts Dmitry Vyukov: 3 posts

People

Translate

site design / logo © 2021 Grokbase