cgo runtime panic

[compiledpanda]

Under heavy load gogoes/cgo randomly panics and outputs panic: runtime error: invalid memory address or nil pointer dereference. I can't tell if this is in gogeos or cgo, so I though I'd report it here first.

go version go1.3rc1 darwin/amd64

Code to reproduce:

package main

import (
    "fmt"
    "github.com/paulsmith/gogeos/geos"
)

func main() {
    for i := 0; i < 100000; i++ {
        geom, _ := geos.FromWKT("LINESTRING (0 0, 10 10, 20 20)")
        bounds, _ := geom.Envelope()
        shell, _ := bounds.Shell()
        points, _ := shell.NPoint()

        for j := 0; j < points; j++ {
            point, _ := shell.Point(j)
            x, _ := point.X()
            y, _ := point.Y()

            if x == -1 && y == -1 {
                fmt.Println("Never called")
            }
        }
    }
}

Stack (line 17 is x, _ := point.X()):

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x4048c30]

goroutine 16 [running]:
runtime.panic(0x40d4600, 0x4187c04)
    /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
github.com/paulsmith/gogeos/geos.(*Geometry).float64FromC(0x0, 0x40e8530, 0x1, 0x41194b0, 0xffffffff, 0x0, 0x0, 0x0)
    /Users/johnclark/go/src/github.com/paulsmith/gogeos/geos/geom.go:904 +0x50
github.com/paulsmith/gogeos/geos.(*Geometry).X(0x0, 0x2, 0x0, 0x0)
    /Users/johnclark/go/src/github.com/paulsmith/gogeos/geos/geom.go:704 +0x68
main.main()
    /Users/johnclark/go/src/github.com/genealogysystems/flechette/bug.go:17 +0xc5

goroutine 19 [finalizer wait]:
runtime.park(0x40157e0, 0x41a4fd8, 0x4189cc9)
    /usr/local/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x41a4fd8, 0x4189cc9)
    /usr/local/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
    /usr/local/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
    /usr/local/go/src/pkg/runtime/proc.c:1445

goroutine 17 [syscall]:
runtime.goexit()
    /usr/local/go/src/pkg/runtime/proc.c:1445
exit status 2

[compiledpanda]

Environment: Mac OSX Mavericks I have geos installed via brew, version 3.4.2

uname -a
Darwin johns-mbp.home 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64

[compiledpanda]

Looks like it is being caused by point, err := shell.Point(j), whic sometimes returns the error Argument is not a LineString

[paulsmith]

I can't recreate this, though I only have go 1.4 and the development version (pre-1.5) installed at the moment.

Looks like it might be a race condition with the finalizers being called during a gc.

[paulsmith]

And now I am able to recreate it using the -race flag.

[Kooper]

Hello,

I observed the same problem, on very similar code:

shape, _ := geos.FromWKT(wkt)
box, _ := shape.Envelope()
boundingLine, _ := box.Shell()
geosCoordinates, _ := boundingLine.Coords()

for _, val := range geosCoordinates {
    coordinates = append(coordinates, s2.LatLngFromDegrees(val.X, val.Y))
}

Which produces SIGSEGV under heavy load (10 goroutines, database queries, millions of WKT strings). The typical stacktrace was:

[signal 0xb code=0x80 addr=0x0 pc=0x7f726b9f0375]

runtime stack:
runtime.throw(0xa52ae0, 0x2a)
        /usr/lib/go-1.6/src/runtime/panic.go:547 +0x90
runtime.sigpanic()
        /usr/lib/go-1.6/src/runtime/sigpanic_unix.go:12 +0x5a

goroutine 103 [syscall, locked to thread]:
runtime.cgocall(0x834dd0, 0xc82013b5b0, 0xc800000000)
        /usr/lib/go-1.6/src/runtime/cgocall.go:123 +0x11b fp=0xc82013b560 sp=0xc82013b530
.../vendor/github.com/paulsmith/gogeos/geos._Cfunc_GEOSCoordSeq_getY_r(0x28ae900, 0x7f7238010030, 0x1, 0xc8202700d0, 0x0)
        .../vendor/github.com/paulsmith/gogeos/geos/_obj/_cgo_gotypes.go:418 +0x41 fp=0xc82013b5b0 sp=0xc82013b560
.../vendor/github.com/paulsmith/gogeos/geos.cGEOSCoordSeq_getY(0x7f7238010030, 0xc800000001, 0xc8202700d0, 0xc800000000)
        .../vendor/github.com/paulsmith/gogeos/geos/cwrappers.go:139 +0x132 fp=0xc82013b610 sp=0xc82013b5b0
.../vendor/github.com/paulsmith/gogeos/geos.(*coordSeq).y(0xc82013b710, 0x1, 0xc114d7e68f5c28f6, 0x0, 0x0)
        .../vendor/github.com/paulsmith/gogeos/geos/coordseq.go:93 +0x61 fp=0xc82013b640 sp=0xc82013b610
.../vendor/github.com/paulsmith/gogeos/geos.coordSlice(0xc82013b710, 0x0, 0x0, 0x0, 0x0, 0x0)
        .../vendor/github.com/paulsmith/gogeos/geos/coord.go:34 +0x191 fp=0xc82013b6e0 sp=0xc82013b640
.../vendor/github.com/paulsmith/gogeos/geos.(*Geometry).Coords(0xc8202b2fd8, 0x0, 0x0, 0x0, 0x0, 0x0)
        .../vendor/github.com/paulsmith/gogeos/geos/geom.go:760 +0x97 fp=0xc82013b720 sp=0xc82013b6e0

As far as I can tell it is an attempt to dereference invalid pointer in C function GEOSCoordSeq_getY_r. Sometimes it was from GEOSCoordSeq_getX_r, several errors were from 'size'-functions. But it is always pointer dereference problem during geos.Coords() call.

As otherwise structures are correct (and I can't reproduce bug if no concurrency involved) my guess was garbage collector, which comes in between calls to geos.FromWKT(wkt)/shape.Envelope()/box.Shell()/boundingLine.Coords() and frees geometries involved in geos.Coords() computations.

To workaround the problem I added silly code to hold variables until after geos.Coords()

geosCoordinates, _ := boundingLine.Coords()
if nil != err {
    log.Printf("%d %d %d", shape, box, boundingLine)
}

Surprisingly this worked well. However I would like to see a correct solution to the pointer ownership problem.