Skip to content
This repository has been archived by the owner on Aug 28, 2021. It is now read-only.

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

Open
fische opened this issue Nov 16, 2017 · 4 comments
Assignees

Comments

@fische
Copy link

fische commented Nov 16, 2017

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
Copy link
Contributor

arv commented Nov 16, 2017

@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
Copy link
Contributor

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
Copy link
Contributor

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

@aboodman
Copy link
Contributor

Or have a special build process.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants