I vendored two projects in my go project. And I successfully compiled my project. When I ran my project, it reported error "panic: http: multiple registrations for /debug/requests". The detailed errors is shown below.
goroutine 1 [running]:
net/http.(*ServeMux).Handle(0x19ae000, 0x126bb20, 0xf, 0x1964540, 0x1297d90)
/usr/local/go/src/net/http/server.go:2270 +0x627
net/http.(*ServeMux).HandleFunc(0x19ae000, 0x126bb20, 0xf, 0x1297d90)
/usr/local/go/src/net/http/server.go:2302 +0x55
net/http.HandleFunc(0x126bb20, 0xf, 0x1297d90)
/usr/local/go/src/net/http/server.go:2314 +0x4b
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/golang.org/x/net/trace.init.0()
/home/chalex/ibm/src/github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/golang.org/x/net/trace/trace.go:115 +0x42
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/golang.org/x/net/trace.init()
<autogenerated>:1 +0x1cd
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/vendor/google.golang.org/grpc.init()
<autogenerated>:1 +0x82
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/third_party/github.com/hyperledger/fabric/protos/peer.init()
<autogenerated>:1 +0x6f
github.own.com/chalex/testfabric/vendor/github.com/hyperledger/fabric-sdk-go/api/apitxn.init()
<autogenerated>:1 +0x44
github.own.com/chalex/testfabric/chaincode/client.init()
<autogenerated>:1 +0x49
main.init()
Does anyone have any idea on how to fix it? I guess it's because the two projects I imported both listen on /debug/requests?
I found the reason. It's because of the golang.org/x/net/trace project. In it's init() function, they handle the debug/request with hard code. So if two projects both import that library, then there is a conflict.
More than one project used golang.org/x/net/trace, and some project saved golang.org/x/net/trace in its vendor directory, so that is causing the conflict. Fix the conflict by deleting others and only leaving one,then the problem will be solved.
Related
cmd.StdoutPipe example at go documentation: https://pkg.go.dev/os/exec#example-Cmd.StdoutPipe does not run in playground.
https://play.golang.org/p/ek7-_Xa_bN3
Error:
fatal error: all goroutines are asleep - deadlock!
goroutine 1 [IO wait]:
internal/poll.runtime_pollWait(0x7faec2ac4e88, 0x72)
/usr/local/go-faketime/src/runtime/netpoll.go:234 +0x89
internal/poll.(*pollDesc).wait(0xc000074180, 0xc000100000, 0x1)
/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:84 +0x32
internal/poll.(*pollDesc).waitRead(...)
/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).Read(0xc000074180, {0xc000100000, 0x200, 0x200})
/usr/local/go-faketime/src/internal/poll/fd_unix.go:167 +0x25a
os.(*File).read(...)
/usr/local/go-faketime/src/os/file_posix.go:32
os.(*File).Read(0xc00000e028, {0xc000100000, 0x28, 0xc000060e80})
/usr/local/go-faketime/src/os/file.go:119 +0x5e
encoding/json.(*Decoder).refill(0xc00007e000)
/usr/local/go-faketime/src/encoding/json/stream.go:165 +0x17f
encoding/json.(*Decoder).readValue(0xc00007e000)
/usr/local/go-faketime/src/encoding/json/stream.go:140 +0xbb
encoding/json.(*Decoder).Decode(0xc00007e000, {0x4cf580, 0xc00000c048})
/usr/local/go-faketime/src/encoding/json/stream.go:63 +0x78
main.main()
/tmp/sandbox2294589397/prog.go:24 +0x185
Program exited.
Locally it's running correctly, no deadlock. I am not able to understand why deadlock happens in go playground.
From the documentation on the os.exec package (which is where this example comes from):
Note that the examples in this package assume a Unix system. They may
not run on Windows, and they do not run in the Go Playground used by
golang.org and godoc.org.
That note doesn't provide a reason, but the reason is presumably that allowing user-provided unix commands to run would give a broader attack surface for malicious code. It's not that it's impossible to allow this in a relatively secure way, but there's various tradeoffs which make disallowing os.exec a natural choice.
I need to remove absolute path in the trace, that corresponds to the imported module. Even though I compile my program so: go build -gcflags=-trimpath=$GOPATH -asmflags=-trimpath=$GOPATH I still get the full path to the module file, where the panic appeared, though the non-module file of the program doesn't show the full path:
goroutine 1 [running]:
monitors/fibre_monitor/logging.FileHandler(0x5e6755, 0x1a, 0x441, 0x0, 0x6fc23ac00, 0x1, 0x500000, 0xc000000002, 0xb)
/home/gtristan/go/src/monitors/fibre_monitor/logging/file_handler.go:182 +0x11f
main.python_logger(0x5e1383, 0x5, 0x5e6755, 0x1a, 0x101)
src/monitors/fibre_monitor/fibre_monitor.go:73 +0x1b5
main.main_check(0x0, 0xc00008e058)
src/monitors/fibre_monitor/fibre_monitor.go:343 +0x65
main.main()
src/monitors/fibre_monitor/fibre_monitor.go:428 +0x56
what can be a solution to get rid of GOPATH everywhere in the trace?
Use the -trimpath argument to go build (not to gcflags or asmflags):
Without -trimpath:
$ go build .
$ ./panic
panic: bleh
goroutine 1 [running]:
main.example(0xc000046738, 0x2, 0x4, 0x473f2b, 0x5, 0xa)
/home/me/stuff/src/github.com/me/testing/panic/main.go:9 +0x39
main.main()
/home/me/stuff/src/github.com/me/testing/panic/main.go:4 +0x72
With -trimpath:
$ go build -trimpath .
$ ./panic
panic: bleh
goroutine 1 [running]:
main.example(0xc000046738, 0x2, 0x4, 0x473f2b, 0x5, 0xa)
github.com/me/testing/panic/main.go:9 +0x39
main.main()
github.com/me/testing/panic/main.go:4 +0x72
Per go help build:
-trimpath
remove all file system paths from the resulting executable.
Instead of absolute file system paths, the recorded file names
will begin with either "go" (for the standard library),
or a module path#version (when using modules),
or a plain import path (when using GOPATH).
I'm Thomas. I have a problem...
so I've never coded in go before, but the more I see the more I like it.
Hehe so I was a little hasty when I posted this please excuse the bad format.
I am new to go so I was not to sure how the install worked, after copying the required files I have managed to get Gitea up and running.
Thanks for the help... Thanks to Gitea and Golang...
2019/04/04 15:39:03 routers/init.go:69:GlobalInit() [T] AppPath: C:/Users/Thomas/go/bin/gitea.exe
2019/04/04 15:39:03 routers/init.go:70:GlobalInit() [T] AppWorkPath: C:/Users/Thomas/go/bin
2019/04/04 15:39:03 routers/init.go:71:GlobalInit() [T] Custom path: C:/Users/Thomas/go/bin/custom
2019/04/04 15:39:03 routers/init.go:72:GlobalInit() [T] Log path: C:/Users/Thomas/go/bin/log
2019/04/04 15:39:03 ...dules/setting/log.go:225:newLogService() [I] Gitea v1.9.0-dev built with go1.12.1
2019/04/04 15:39:03 ...dules/setting/log.go:265:newLogService() [I] Gitea Log Mode: Console(Console:info)
2019/04/04 15:39:03 ...les/setting/cache.go:42:newCacheService() [I] Cache Service Enabled
2019/04/04 15:39:03 ...s/setting/session.go:34:newSessionService() [I] Session Service Enabled
2019/04/04 15:39:03 routers/init.go:37:checkRunMode() [I] Run Mode: Development
panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: The system cannot find the path specified.
goroutine 1 [running]:
code.gitea.io/gitea/vendor/github.com/go-macaron/i18n.initLocales(0xc0001a0755, 0x0, 0x163622a, 0xb, 0xc0001717a0, 0x1644590, 0x12, 0xc0001ca160, 0x16, 0x16, ...)
C:/Users/Thomas/go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/i18n/i18n.go:57 +0x6f6
code.gitea.io/gitea/vendor/github.com/go-macaron/i18n.I18n(0xc00006c0c0, 0x1, 0x1, 0x0, 0x0)
C:/Users/Thomas/go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/i18n/i18n.go:158 +0xf4
code.gitea.io/gitea/routers/routes.NewMacaron(0xc000285040)
C:/Users/Thomas/go/src/code.gitea.io/gitea/routers/routes/routes.go:165 +0x869
code.gitea.io/gitea/cmd.runWeb(0xc000285040, 0x0, 0x0)
C:/Users/Thomas/go/src/code.gitea.io/gitea/cmd/web.go:125 +0xb5
code.gitea.io/gitea/vendor/github.com/urfave/cli.HandleAction(0x1418fa0, 0x1695ed0, 0xc000285040, 0xc00006e8a0, 0x0)
C:/Users/Thomas/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:471 +0xb4
code.gitea.io/gitea/vendor/github.com/urfave/cli.(*App).Run(0xc0001684e0, 0xc000078170, 0x1, 0x1, 0x0, 0x0)
C:/Users/Thomas/go/src/code.gitea.io/gitea/vendor/github.com/urfave/cli/app.go:246 +0x57b
main.main()
C:/Users/Thomas/go/src/code.gitea.io/gitea/main.go:60 +0x42d
C:\Windows\system32>
MichaelA:
welcome! I'm afraid your question is Kind of "not a question".
You just dumped some Code and are rather unprecise on what you want to achieve.
Please have a look at stackoverflow.com/help/how-to-ask and edit your question.
Keep in mind: If you don't think it is worth to invest some time into creating a
good question, why should we invest time to create a good answer?
Volker :
This does not look like a build error but like a runtime error because you are
missing a file conf/locale/locale_en-US.ini. Make sure to have this file with
proper content.
Thanks! 🎈
I am trying to build CockroachDB from sources on a RPi 3, following a couple of posts (this and this).
My RaspberryPi setup:
OS: 2018-06-27-raspbian-stretch
CPU: ARMv7 rev 4(v71)
Mem: 1G + SWAP: 1.5G
Go version: go1.11 linux/arm
I fixed a couple of errors regarding 3rd party libraries while 'make'ing it but now I got stuck on this:
pi#raspberrypi:~/work/go/src/github.com/cockroachdb/cockroach $ make build TAGS='stdmalloc' -j2
GOPATH set to /home/pi/work/go
go build -o cockroach -v -tags 'stdmalloc make arm_linux_gnueabihf_stdmalloc' -ldflags '-X github.com/cockroachdb/cockroach/pkg/build.typ=development -extldflags "" -X "github.com/cockroachdb/cockroach/pkg/build.tag=v2.2.0-alpha.00000000-668-gf76d921f42-dirty" -X "github.com/cockroachdb/cockroach/pkg/build.rev=f76d921f4262356fde83312d0f471262d995f1e0" -X "github.com/cockroachdb/cockroach/pkg/build.cgoTargetTriple=arm-linux-gnueabihf" -X "github.com/cockroachdb/cockroach/pkg/build.utcTime=2018/09/11 12:47:32"' ./pkg/cmd/cockroach
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2372b8]
goroutine 1 [running]:
runtime/internal/atomic.goLoad64(0x3d65bdc, 0x0, 0x5607a20)
/usr/local/go/src/runtime/internal/atomic/atomic_arm.go:124 +0x1c
github.com/cockroachdb/cockroach/pkg/util/humanizeutil.(*BytesValue).String(0x55fb578, 0x5607a01, 0x56d9ea0)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/util/humanizeutil/humanize.go:109 +0x28
github.com/cockroachdb/cockroach/pkg/cli.(*bytesOrPercentageValue).String(0x57b4920, 0x56d9ea0, 0x7)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags_util.go:492 +0x20
github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag.(*FlagSet).VarPF(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x56d2900, 0x169, 0x56d9ea0)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag/flag.go:778 +0x24
github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag.(*FlagSet).VarP(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x56d2900, 0x169)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag/flag.go:786 +0x5c
github.com/cockroachdb/cockroach/pkg/cli.VarFlag(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x0, 0x0, 0x1fa4462, ...)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags.go:129 +0x6c
github.com/cockroachdb/cockroach/pkg/cli.init.5()
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags.go:324 +0x6c0
Makefile:1288: recipe for target 'docs/generated/settings/settings.html' failed
make: *** [docs/generated/settings/settings.html] Error 2
make: *** Deleting file 'docs/generated/settings/settings.html'
Any ideas what might be wrong?
thanks for the question. I was the original author of that blog post. It looks like you're running into an issue related to https://github.com/golang/go/issues/9959. It looks like golang requires 64-bit alignment of 64-bit words when atomically accessed. This is somewhat tricky to enforce across an entire project. Still, we can try to get this working by removing the atomic access on pkg/util/humanizeutil/humanize.go:109 (which doesn't look necessary) and replacing it with return IBytes(*b.val). That should at least get you past this roadblock. There may be other issues you run into after this though. Unfortunately, CockroachDB has never set up CI around a 32-bit ARMv7 build because 32-bit architectures have never been officially supported by the project.
However, a 64-bit ARMv8 build is more actively maintained. In fact, an entire cross-compilation toolchain has been introduced to build CockroachDB for ARMv8 on an x86_64 host. Compilation using this toolchain can be kicked off by running build/builder.sh mkrelease arm64-linux-gnueabi. The resulting binary can be dropped onto a RaspberryPi running a 64-bit OS like https://wiki.debian.org/RaspberryPi3. I actually tried this out last week and ran into no problems.
My go code errors out with a strack trace like this:
unexpected fault address 0x0
fatal error: fault
[signal 0xb code=0x80 addr=0x0 pc=0x407d50]
goroutine 52246872 [running]:
runtime.throw(0xad6a77)
/usr/local/go/src/pkg/runtime/panic.c:464 +0x69 fp=0xc214d2c1f8
runtime.sigpanic()
/usr/local/go/src/pkg/runtime/os_linux.c:237 +0xe9 fp=0xc214d2c210
hash_lookup(0x671ec0, 0xc21001eed0, 0xc214d2c2d0)
/usr/local/go/src/pkg/runtime/hashmap.c:502 +0x150 fp=0xc214d2c290
runtime.mapaccess(0x671ec0, 0xc21001eed0, 0xc214d2c318, 0xc214d2c328, 0xc214d2c330)
/usr/local/go/src/pkg/runtime/hashmap.c:1004 +0x57 fp=0xc214d2c2c0
runtime.mapaccess2(0x671ec0, 0xc21001eed0, 0x389c, 0x2060009ae, 0xad4dc0, ...)
/usr/local/go/src/pkg/runtime/hashmap.c:1061 +0x5d fp=0xc214d2c308
growmobile.com/rtb/cache.HistogramCheck(0xc2121eafd0, 0xc, 0xeca93c6a0, 0x852a9f8, 0xad4dc0, ...)
/mnt/rtb_server/go/src/growmobile.com/rtb/cache/histogram_cache.go:211 +0x16b fp=0xc214d2c798
growmobile.com/rtb/controller.processBidRequest(0xc2121eafd0, 0xc, 0xeca93c6a0, 0x852a9f8, 0xad4dc0, ...)
/mnt/rtb_server/go/src/growmobile.com/rtb/controller/bidder_logic.go:272 +0x7c2 fp=0xc214d2e928
----- stack segment boundary -----
growmobile.com/rtb/controller.Bid(0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/mnt/rtb_server/go/src/growmobile.com/rtb/controller/controller.go:96 +0x903 fp=0x7f79f8dd9da0
net/http.HandlerFunc.ServeHTTP(0x800850, 0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/usr/local/go/src/pkg/net/http/server.go:1220 +0x40 fp=0x7f79f8dd9dc0
net/http.(*ServeMux).ServeHTTP(0xc21001e660, 0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/usr/local/go/src/pkg/net/http/server.go:1496 +0x163 fp=0x7f79f8dd9df8
net/http.serverHandler.ServeHTTP(0xc21001fa00, 0x7f7a14250ed8, 0xc2197b3a00, 0xc2157f9dd0)
/usr/local/go/src/pkg/net/http/server.go:1597 +0x16e fp=0x7f79f8dd9e38
net/http.(*conn).serve(0xc215d60a00)
/usr/local/go/src/pkg/net/http/server.go:1167 +0x7b7 fp=0x7f79f8dd9f98
runtime.goexit()
/usr/local/go/src/pkg/runtime/proc.c:1394 fp=0x7f79f8dd9fa0
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1644 +0x28b
goroutine 1 [chan receive]:
main.serve()
/mnt/rtb_server/go/src/growmobile.com/rtb/rtb_server/rtb_server.go:71 +0x5f0
main.main()
/mnt/rtb_server/go/src/growmobile.com/rtb/rtb_server/rtb_server.go:86 +0x1d8
At the time it is trying to access a hash which is a struct that maps to a pointer. The hash is a global one and looks like this:
var histogramCache = make(map[model.HistogramKey]*model.HistogramValue)
The access is a very standard access which looks like:
value, ok := histogramCache[key]
I tried to google something similar but could not find it. I do not use cgo or assertions.
This is the go version we are using: go version go1.2 linux/amd64
Thank you, any help would be appreciated.
Maps are not safe for concurrent access. This might very well be the reason why your code is failing.
Use a central goroutine (see this example) and retrieve things using channels or use locking tools from sync.
Reinstalling the goland package fixed this problem for me. Some dependencies had been replaced by another package or were not correctly installed.