BoltDB panics on cursor search since April update #3162
Comments
|
Same here. This causes etcd to crash which again causes test problems with kubebuilder: kubernetes-sigs/kubebuilder#364 |
|
This is still an ongoing issue. =/ |
|
Looks like this issue in BoltDB cause to crashing docker: |
|
I believe this is not a boltdb issue, but an issue with how WSL handles mmap calls from what I've observed. |
|
This also apparently happens on top of ZFS, speciflcally from an inside an Ubuntu LXC container on an Arch host which actually runs the ZFS storage pool on which the container resides: Removing and reinstalling docker has no effect, its proper broken. Any way to disable the behavior via config? |
|
@sempervictus Just wanted to clarify, you experienced this running Arch on WSL with containers in that? Also have you confirmed you can reproduce it in Arch on WSL as well? I've personally not considered trying different distros, because I've been fairly certain it's the compatibility layer on Windows' end. |
|
Yes Occam says this is variation #3451 #902. It wasn't duped because there is no signature |
|
@petrosam: no, plain old Linux kernel, just using a filesystem originated in solaris. Edit: in my experience golang has some issues with POSIX semantics, it makes assumptions about features like vdso, map hints, etc. ZFS on Linux has some differences from illumos and BSD in the memory management subsystem - Linux memory management is in itself somewhat different from the unix-ish OS'. So mmapped files in this context may well show errors you're seeing on other systems with not-exactly-linux semantics. I'd see how the BSD Linux containers run this, may happen there too. |
That's possible. There's an additional challenge in that platform nuances can be worked-around in the source code with configuration knobs on other platforms like *BSD or MacOS (be it the filesystem or MM or IPC mechanisms or whatever). WSL pretends to be Real Linux, so the tiniest diverge in behavior (documented or otherwise) from the real thing can cause subtle problems. Constructive thing to do would be to try to convince someone familiar with the BoltDB (and golang) internals to take a look. |
|
Yeah I'm seeing this in the Ubuntu distribution on WSL as well. Retried in an admin terminal after cgroups mount and things spun up No luck with an image but at least it's a step forward |
|
This issue has been on wsl for a very long time. I'm really hope it can get fixed soon. |
As an initial matter, this issue doesn't have a repro. "1. make sure GO is installed". Yes, someone probably could have looked up how to do that. Turns out someone didn't, and this went chirping crickets (along with many other issues without a repro). Secondly, one year (May 2018) doesn't set any distance records. But you made me look on a hunch... |
|
$ cd /home/rfikki/downloads go1.12.5.linux-amd64.tar.gz 100%[=================================================>] 122.01M 32.2MB/s in 4.1s 2019-05-15 07:40:43 (30.1 MB/s) - ‘go1.12.5.linux-amd64.tar.gz’ saved [127938445/127938445] $ ls func main() { } File maain.go saved goroutine 1 [running]: |
Well, yeah. I have pruned your cross post. |
|
The release version of Docker does not run under WSL on Ubuntu 18.04 because of this bug. Is there any eta anyone knows from Microsoft of when the bug fix will be in the release version of Windows ? |
|
I'm seeing the same failure using the Elvish shell which uses BoltDb. My Windows 10 VM is up to date. I don't see any reason to think https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-18890 has resolved this issue. |
Your Windows build number:
Microsoft Windows [Version 10.0.17134.1]
What you're doing and what's happening
go get github.com/boltdb/boltgo build main.go./mainBoltDB panics with:
I expect no panics for this code :)
The text was updated successfully, but these errors were encountered: