Comment 1:

could you please provide a small test case that demonstrate this problem?

Comment 2:

I tried writing a small reproducer, but I can't get it to fail. I'm not sure what
triggers the failure. 
It only occurs when running through the whole msgpack.Decode benchmark. All tests pass,
but running benchmark fails. The error occurs in the benchmark after the 92'th iteration
i.e.
    for i := 0; i < b.N; i++ {
        log(">>>> i: %v", i)
        // <snip>
    }
Only when i=92, then I get the error. So it seems to be an issue under some kind of load.
Instead of waiting till I could create a small reproducer, I decided to file it hoping
that something may jump out to folks familiar with the code.
If running the benchmark directly will help, you can use the following steps to
reproduce:
  git clone https://github.com/ugorji/go-msgpack .
  git checkout dev
  go test -bench '_Msgpack__Decode'
You may not see the error on your first run. The second time you run it (and
thereafter), you will.
Note: The benchmark above depends on:
    vmsgpack "github.com/vmihailenco/msgpack"
    "launchpad.net/mgo/bson"
You should 'go get' these libraries. Alternatively, you can edit the benchmark_test.go
to remove references to bson and vmsgpack.

Comment 3:

Labels changed: added priority-soon, go1.1, removed priority-triage.

Comment 4:

ugorji: you should still provide the already edited version of benchmark_test.go that
doesn't reference bson and vmsgpack in order to help debugging experience.
I don't think anything jumps out: segfaults in new GC or runtime are common in late days
and don't point out at anything in particular.

Comment 5:

possibly related, https://groups.google.com/d/msg/golang-nuts/R-d6yIMwUPE/WjOIshye8YQJ

Comment 6:

The tests want to run a Python script that doesn't work on my machine, and the correct
import path for mgo is labix.org/v2/mgo, not launchpad.net/mgo. Can you correct that?

Comment 7:

Hi Remy,
I just saw your message. I had started working on separating both from it. I'd update
this Issue in a few minutes once uploaded.

Comment 8:

Hi Remy,
Just updated. Please can you try again.
I moved all the tests which require a local installation or external setup (go get, etc)
to an ext_dep_test.go, which is excluded by default (//+build ignore).
You should be able to re-fetch and run as before.
Thanks.

Comment 9:

After a bisection session I obtained that:
* It is buggy for a long time, at least since ~13 Feb.
* For some reason network poller hid the problem:
WORKS:
16202   a45e271add6c   2013-03-12 21:39 +0400   dvyukov
  runtime: fix build
NOT WORKS:
16200   a364be6bc34f   2013-03-12 11:46 -0400   rsc
  encoding/xml: name space bug fixes
(16201 does not build)
* Then the problem reappeared as reported by ugorji:
NOT WORKS:
16243   7bcfc5879223   2013-03-14 13:48 +0400   dvyukov
  runtime: revert UseSpanType back to 1
WORKS:
16241   5af2130aec77   2013-03-14 10:38 +0400   dvyukov
  runtime: integrated network poller for darwin
(16242 does not build).
The revisions that work are exactly those where UseSpanType = 0 in runtime.h
(accidentally set by Dmitry when submitting runtime polling).

Comment 10:

Fix: https://golang.org/cl/7913043/
Please test.

Status changed to WaitingForReply.

Comment 11:

Tested a few times. Everything works now without errors.
LGTM.

Comment 12:

This issue was closed by revision 54dffda.

Status changed to Fixed.

Comment 13:

Doesn't seem to be fixed.
See those failed linux/386 builds:
http://build.golang.org/log/7576e9d5aa2c4ac8a29b2d4187e5883259fca5a8
http://build.golang.org/log/2f3402ee9cf50eca70723925ede1d0a888d53d74
linux/amd64:
http://build.golang.org/log/fa5834a76f65e1a3a2564bc748f0487cf9166436

Comment 14:

Status changed to Accepted.

Comment 15:

This issue was fixed in two steps.
#13 has been fixed by revision 61fa5c7d741f
What was the proper procedure in a situation like this? Reopen the issue after seeing
#13 and then submit a CL containing "Fixes issue NNN" to close it again?

Comment 16:

This issue was closed by revision bf1f461.

Status changed to Fixed.

Comment 17:

Re comment #15, it is okay to check in multiple CLs with 'Fixes issue NNNN.' The issue
tracker will attach them to the issue correctly, though of course only the first will
change the status to Fixed. It is also okay to reopen the issue if you want a reminder
that something needs fixing, but if you've already got the fix ready it's okay to skip
that step and just mail the fix.
Thanks.