attic-labs / noms

The versioned, forkable, syncable database
Apache License 2.0
7.45k stars 267 forks source link

Duplicate import of golang.org/x/net/trace causing "multiple registrations for /debug/requests" #3786

Open fische opened 6 years ago

fische commented 6 years ago

Hi,

It seems that golang.org/x/net/trace has been vendored using gx. This means that some packages - that have also been vendored with gx - import it with a path that looks like gx/ipfs/$HASH/go-net/trace.

In my case, I am also using a package that imports golang.org/x/net/trace with the right path. Therefore, the init functions of golang.org/x/net/trace and gx/ipfs/$HASH/go-net/trace - which are the same one - are both called.

The problem is that this function tries to register 2 handlers to the DefaultServeMux of the net/http package (i.e. https://github.com/golang/net/blob/master/trace/trace.go#L112). Thus, if it gets called twice, it will panic with the following error: http: multiple registrations for /debug/requests.

For example, the following piece of code:

package main

import (
    "log"

    _ "google.golang.org/grpc"

    _ "github.com/attic-labs/noms/go/spec"
)

func main() {
    log.Println("Hello world!")
}

... will produce the following output:

panic: http: multiple registrations for /debug/requests

goroutine 1 [running]:
net/http.(*ServeMux).Handle(0x15083c0, 0xdbb5c6, 0xf, 0x1413900, 0xf07ca8)
        /usr/lib64/go/src/net/http/server.go:2270 +0x627
net/http.(*ServeMux).HandleFunc(0x15083c0, 0xdbb5c6, 0xf, 0xf07ca8)
        /usr/lib64/go/src/net/http/server.go:2302 +0x55
net/http.HandleFunc(0xdbb5c6, 0xf, 0xf07ca8)
        /usr/lib64/go/src/net/http/server.go:2314 +0x4b
github.com/attic-labs/noms/vendor/gx/ipfs/QmTEmsyNnckEq8rEfALfdhLHjrEHGoSGFDrAYReuetn7MC/go-net/trace.init.0()
        $GOPATH/src/github.com/attic-labs/noms/vendor/gx/ipfs/QmTEmsyNnckEq8rEfALfdhLHjrEHGoSGFDrAYReuetn7MC/go-net/trace/trace.go:110 +0x42
github.com/attic-labs/noms/vendor/gx/ipfs/QmTEmsyNnckEq8rEfALfdhLHjrEHGoSGFDrAYReuetn7MC/go-net/trace.init()
        <autogenerated>:1 +0x549
github.com/attic-labs/noms/vendor/gx/ipfs/QmTBxwy8cerzXbZQFUwTBCSxx55jUgVzudFcpmnAHUGuPy/badger.init()
        <autogenerated>:1 +0x5f
github.com/attic-labs/noms/vendor/gx/ipfs/QmUamAGkvPp1w84dfc2YMy9ic6iyBvaRoaTiaat8Crtawq/go-ds-badger.init()
        <autogenerated>:1 +0x4b
github.com/attic-labs/noms/vendor/github.com/ipfs/go-ipfs/repo/fsrepo.init()
        <autogenerated>:1 +0x87
github.com/attic-labs/noms/go/ipfs.init()
        <autogenerated>:1 +0xb1
github.com/attic-labs/noms/go/spec.init()
        <autogenerated>:1 +0x87
main.init()
        <autogenerated>:1 +0x4e
exit status 2
arv commented 6 years ago

@willhite @aboodman This is because we are not importing ipfs in the normal way. Can we import ipfs in the normal way instead of using the hash version (gx)

aboodman commented 6 years ago

This is the system that ipfs itself uses. The "normal" thing doesn't really work for IPFS. I can't remember why (I think that go get doesn't understand the gx-based paths).

I'm not sure what the right solution is.

aboodman commented 6 years ago

Perhaps the ipfs samples should be in a separate repo or something.

aboodman commented 6 years ago

Or have a special build process.