unexpected fault address; fatal error: fault

[tonyghita]

I've recently observed this fatal error seemingly related to uintFromBytes (vendored at v1.2.0), and was wondering if there was anything that stood out from the stack trace.

$ go version
go version go1.8.3 linux/amd64

unexpected fault address 0x7fba5014a240
fatal error: fault
[signal SIGBUS: bus error code=0x2 addr=0x7fba5014a240 pc=0x82d5bd]

goroutine 946477698 [running]:
runtime.throw(0x14a1d41, 0x5)
        /usr/local/go/src/runtime/panic.go:596 +0x95 fp=0xc462aa4618 sp=0xc462aa45f8
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:287 +0xf4 fp=0xc462aa4668 sp=0xc462aa4618
<project>/vendor/github.com/oschwald/maxminddb-golang.uintFromBytes(0x0, 0x7fba5014a240, 0x3, 0x36e136, 0x10)
        /go/src/<project>/vendor/github.com/oschwald/maxminddb-golang/decoder.go:663 +0x1d fp=0xc462aa4670 sp=0xc462aa4668
<project>/vendor/github.com/oschwald/maxminddb-golang.(*Reader).readNode(0xc4219e1400, 0x60, 0x0, 0x402672, 0x14a8694, 0xa)
        /go/src/<project>/vendor/github.com/oschwald/maxminddb-golang/reader.go:228 +0xa2 fp=0xc462aa46e0 sp=0xc462aa4670
<project>/vendor/github.com/oschwald/maxminddb-golang.(*Reader).findAddressInTree(0xc4219e1400, 0xc435169ccc, 0x4, 0x4, 0x4, 0x4, 0x10)
        /go/src/<project>/vendor/github.com/oschwald/maxminddb-golang/reader.go:187 +0xb9 fp=0xc462aa4750 sp=0xc462aa46e0
<project>/vendor/github.com/oschwald/maxminddb-golang.(*Reader).lookupPointer(0xc4219e1400, 0xc435169cc0, 0x10, 0x10, 0x4, 0x4, 0xc435169d00)
        /go/src/<project>/vendor/github.com/oschwald/maxminddb-golang/reader.go:169 +0x9b fp=0xc462aa47c0 sp=0xc462aa4750
<project>/vendor/github.com/oschwald/maxminddb-golang.(*Reader).Lookup(0xc4219e1400, 0xc435169cc0, 0x10, 0x10, 0x11c86a0, 0xc435169d10, 0x144db80, 0xc430313ee0)
        /go/src/<project>/vendor/github.com/oschwald/maxminddb-golang/reader.go:110 +0x4d fp=0xc462aa4808 sp=0xc462aa47c0

[oschwald]

Is it possible another process truncated or modified the database file around the time that this happened? Was there anything unusual printed in the kernel logs?

[tonyghita]

Is it possible another process truncated or modified the database file around the time that this happened?

Yes, I think you're right.

At the same time the database was Opened, a cron job was running to download an updated database file. The file opened without error and the application ran correctly until (presumably) a lookup was performed on a part of the database that was not present at the time of the Open due to the in-progress download.

The chosen solution is to download the updated database to a temporary directory, then atomically mv it to where the application expects it to be, after the download has completed.

I'm not sure if there is anything the library can do in this case, so I'm going to close the issue. Hopefully it helps someone else if they run into this edge case!

[helios741]

@tonyghita I also meet this problem as you, could you tell how to solve this the problem.