-
-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fatal error: sync: Unlock of unlocked RWMutex #300
Comments
Thanks for reporting, this is a strange bug and I can't reproduce it. Never seen it before. Can you show the output of |
It's the latest one |
This comment was marked as spam.
This comment was marked as spam.
Same on freebsd 13.0 on arm64, using either the v1.9.2
|
@alexsavage thanks for that output, that should be enough for me to fix this issue. Concerning it's happening even with v1.9.2. I will look into it and try to fix it tomorrow evening (March 23). |
@OfekShochat @alexsavage could you answer some questions to help me understand the bug? I've been looking into it but it's tricky.
I would also appreciate if you both could share your This hopefully will help me track down why this is occurring. Confused at the moment. |
Instantly and consistantly. Ive just built it, no further config. I can try and gdb it which will give you more info than you're asking, though it might take some time for me (not at home). But I'm confused as you are, but I'm not that familiar with go's internals (when does it lock? When does it unlock? Why does it even unlock if it didn't lock? Afaik it doesnt schedule it like a async runtime which would make sense, somewhat, to lock on time.Sleep). It would maybe make sense on viper.getInt cuz it has to lock to get the shared(?) memory. And then if this is true, it might be a go issue. |
Hmm, seems like the problem solved itself? I had many disk related issues in the last week but well idk. I'm going to leave this issue open though |
Thanks. So sounds like you have no subscriptions and the default config. Really not sure why this is happening then.
Wow, it no longer appears? Let me know if it comes back or if you can figure out what is causing it.
Yes thanks. I'd like to continue debugging with @alexsavage to get this fixed. |
This is on a clean user with no amfora files - here is the config.toml that got dropped. I don’t have a subscriptions.json file at all, though! On the “disk slow” thought - I am running on a Raspberry Pi 4, not slow but not a high end server or anything. Perhaps there is a race condition between some of the default files being created, and the startup? |
Thanks for sharing your config. Of course it's just the default one because it's a fresh install, so I'm not sure if there's many clues there.
That makes sense, it's only created once you add a subscription. I tried running Amfora v1.9.2 on my computer, no config file and no subscriptions file, and I still can't replicate this. Frustrating.
I don't think so, I can't see where that would happen. I guess it's possible though, and @OfekShochat did mention disk issues above. Could you try this binary instead? Just built this myself, just want to sanity check this isn't some strange build issue. Don't expect it will be. |
Okay, on to something! The Looks like when
|
Thanks for this info. I think I've figured a lot of this out. You don't have to read all this, but I'm documenting the cause of the bug here. Check down at the bottom for a fix for you to try. The second section of the stack trace, such as Here, I was able to get my own similar crash by running Amfora v1.9.2 in a chroot (unrelated goroutines removed):
The stack trace leads me to cview, an upstream dependency used as a terminal framework. Specifically Here is the relevant code (note the lines matching the stack trace): https://code.rocketnine.space/tslocum/cview/src/commit/7e8817f20bdc/application.go#L223-L243 func (a *Application) Init() error {
a.Lock()
defer a.Unlock()
return a.init()
}
func (a *Application) init() error {
if a.screen != nil {
return nil
}
var err error
a.screen, err = tcell.NewScreen()
if err != nil {
a.Unlock()
return err
}
if err = a.screen.Init(); err != nil {
a.Unlock()
return err
} The This leads to a double-unlock, causing the stack trace we've seen. So, why is calling
So in the theory there are two things to fix:
As a quick fix for now, I'll update tcell in-place, and we can see how that goes. See below. For the future, an issue needs to be filed in cview, and then I should look at all the differences between the current cview version imported and the latest one. If I can't upgrade easily, I can fork cview, but ideally the upgrade would be made. Since tmux is commonly used (although your Please try this binary and let me know if it fixes your issue with Amfora running in tmux. |
@OfekShochat please let me know what terminal emulators (and emulators within emulators like tmux, screen, etc) you were using when Amfora crashed and didn't crash. If you could also include the output of your |
Ive used alacritty, with leftwm on both occasions |
Ok thanks. Not sure what the issue would be then but feel free to report back if you figure more out. |
@alexsavage from some discussion with others online, it seems that most people have no issue with Amfora in tmux even with the same So another solution would be to install some other package on your system, probably some ncurses stuff, that can provide the terminfo you need. Perhaps this is related to FreeBSD, as on Linux having the ncurses package might be more common? Not sure. Once this is all said and done I'll see if it really warrants a new release, might be more of an edge case. |
Installing |
Great to hear this! Thanks you. Could you also confirm whether the binary I uploaded fixes the problem (with the A post-install message mentioning tmux and ncurses sounds appropriate, good idea. |
Ah wait, I think this it is a specific terminal issue. When it worked it wasn't alacritty (but wasn't leftwm too) |
Same crash with the test binary and no
Suggested the workaround to the ports maintainer at Bugzilla 262863 |
@alexsavage thanks for testing that. I see you've filed a tcell bug and figured out why this is occurring at all, that's great thank you, you've saved me that work.
@OfekShochat could you narrow down the bug to either alacritty or leftwm? And after that try this binary (Linux 64-bit), and let me know if it fixes the issue. Thanks! |
its probably the terminal, the window manager should have nothing to do with it. and it actually would make sense cuz I remember something about alacritty and 256color (for example in vim I have to set it to work with colors) |
Created cview issue: https://code.rocketnine.space/tslocum/cview/issues/85 |
There is a now a fix for this error, described in the cview issue linked above. It requires upgrading cview though, so I would need to evaluate that and fix and bugs that arise from upgrading. |
sure, thank you! quite cool. dont count on me, but if I have time Id to help |
Same thing happening to me as well. Arch Linux 2022/07/01 at 13:25 CEST. |
What's your terminal emulator? Read the conversation :) |
GNOME terminal |
https://code.rocket9labs.com/tslocum/cview/releases/tag/v1.5.9 Patrycja should have credit for finding a fix for the cview issue in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57975 |
hello!
Ive looked at gemini quite some time ago, and looking back at it, its gotten really cool. though when I tried to open amfora after installing it in arch (tried both the amfora-git and amfora packages) I got this traceback:
the same thing is happening when compiling from source.
thanks aot
The text was updated successfully, but these errors were encountered: