signal 11 on vmware w/ linux?

[jimr]

Hi folks,

Have any of you folks run into problems with your go executables (not using cgo directly) getting a signal 11 under vmware linux?

I've got a vmware instance running debian in 64-bit mode, and I'm finding my program (built w/ 6g/6l) will sometimes dump core with a signal 11 (invalid memory access).  I tried re-compiling with 6l using the -e flag to get at what it was doing, but all I got was a minimal trace:

Program terminated with signal 11, Segmentation fault.
#0  0x00000000004260c0 in runtime.sighandler (sig=void, info=void, context=void, gp=void) at /usr/local/src/go/src/pkg/runtime/linux/amd64/signal.c:53
53    runtime·sighandler(int32 sig, Siginfo *info, void *context, G *gp)
Loading Go Runtime support.
(gdb) where
#0  0x00000000004260c0 in runtime.sighandler (sig=void, info=void, context=void, gp=void) at /usr/local/src/go/src/pkg/runtime/linux/amd64/signal.c:53
#1  0x0000000000428a58 in runtime.sigtramp () at /usr/local/src/go/src/pkg/runtime/linux/amd64/sys.s:105
#2  0x0000000000428a6c in runtime.sigignore () at /usr/local/src/go/src/pkg/runtime/linux/amd64/sys.s:114
#3  0x0000000000000000 in ?? ()

As far as I can tell this program runs just fine under my mac, so I'm trying to narrow down the possible causes.  I'm in the middle of rebuilding my go tree to the latest release to see if that has any impact.

My big suspicion is that there's something odd going on within my vmware, possibly due to a kernel upgrade that was applied to it within the past few weeks.   I was wondering if anyone here might have experienced a similar problem...


Jim

[jimr]

Hrm.. It appears to be related to my use of pprof.  I've got part of the code set up to trigger profiling:

...
        f, err := os.Create("collections.pprof")
        if err != nil {
            log.Fatal(err)
        }
        pprof.StartCPUProfile(f)
        resources, err := u.Resources(cacheEntry.Collections)
        pprof.StopCPUProfile()
...

When I disable the pprof calls I can run the program 20 times in a row w/o any problem.  With the pprof calls set up it invariably core dumps by run #10.


Jim

[JONNALAGADDA Srinivas]

        Similarly, using `6prof' with a small sampling interval causes crashes once in a while.  However, I have not been able to deterministically reproduce the problem so far.  One factor that certainly seems to play a part is memory allocation.  The program that crashes with 6prof allocates a very large number of small chunks.

        On the other hand, I have not had a crash caused by 6prof, when running other programs that are not as memory-hungry.

                                                            Greetings,

                                                                    JS

____

http://oneofmanyworlds.blogspot.com

[jimr]

Ah, that's interesting to know.  My program is making a huge number of small
allocations.  In fact, that's why I'm using the profiler right now -- to see where it
is making the most allocations to check whether or not I can restructure the code
to be more efficient!

Jim