SIGSEGV panic when a voice reconnect is triggered #298
Comments
|
Right off the bat, this is not the same. It's similar but you call close as soon as possible. I would suggest you debug it to see if the close is what causing the issue. First off, Discord states that the guild id is optional. So if someone sends your bot a DM, there won't be a guild ID. that would definitely cause an error here. I'd suggest injecting a middleware that filters out DM messages. Note that keeping the guild id dynamic, while the channel id is hardcoded causes some concern. |
|
If I run this: type ZahtBot struct {
}
func (zb *ZahtBot) zaht(session disgord.Session, m *disgord.MessageCreate) {
log.Println("Zahting...")
// the line below this comment is where my code is crashing
voice, err := session.VoiceConnect(m.Message.GuildID, 673893473409171477)
if err != nil {
log.Printf("Voice Connect error: %+v\n", err)
return
}
defer voice.Close()
err = voice.StartSpeaking()
if err != nil {
log.Printf("Start Speaking error: %+v\n", err)
return
}
f, _ := os.Open("test.dca")
defer f.Close()
err = voice.SendDCA(f)
if err != nil {
log.Printf("Send DCA error: %+v\n", err)
return
}
err = voice.StopSpeaking()
if err != nil {
log.Printf("Stop Speaking error: %+v\n", err)
return
}
log.Println("Zahted!")
}the bot plays the sound, no issue. However, after the file has been transmitted, I get the following: This error can be ignored, although ugly and should be patched. But your bot will still be functional. |
|
I can also say that I tried the following: And then I spammed the text channels with new messages. I still was not able to get this error. |
|
The code can also be reduced to: func (zb *ZahtBot) zaht(session disgord.Session, m *disgord.MessageCreate) {
log.Println("Zahting...")
// the line below this comment is where my code is crashing
voice, err := session.VoiceConnect(m.Message.GuildID, hardcodedChannelID)
if err != nil {
log.Printf("Voice Connect error: %+v\n", err)
return
}
defer voice.Close()
log.Println("SUCCESS")
}
Edit: it's unrelated. |
andersfylling
changed the title
|
Another person in Discord stated a similar issue. After reviewing his logs, I noticed it always happened after a reconnect took place. This issue is missing logs so I can't figure out if it's the same situation. Given that it happens every time, I'm feeling uncertain if it's related. Can you give more insight on the following:
|
|
First off thanks for the insight. In reference to the dynamic Guild ID and the static channel ID, I'm waiting to figure out how to retrieve the voice channel that the message sender is in (if they are in one). I don't believe there is a way to do that in this library yet, so that's why I created issue #288. Before this bot goes public, I will either have to figure it out or submit a PR against this (amazing) library. You can view my bot code here. This way you can test my exact environment if you wanted, because it seems like you aren't able to replicate the bug. I will be posting better logs in a moment. |
|
Here are some logs that show a crash that happens when the bot is spammed. You can tell when the bot starts and stops voice-ing by the 'Zahting...' and 'Zahted!' log lines. In this log dump, the bot successfully zaht's once, then crashes on the second time. |
|
Okay, I see it's related to the reconnect. Is this because you keep forcing the bot to connect to a already connected voice channel? |
andersfylling
changed the title
andersfylling
changed the title
|
Here is the log dump from the Docker container + DigitalOcean droplet: |
|
Yeah, that's another reconnect. |
|
For the Docker+DO issue, I know for a fact that the bot is not connected to anything. There are no current instances in the wild, and I don't spam it while testing. It crashes on the first zaht; it connects, doesn't voice anything, then lingers. |
|
From the logs we do see that it happens on a reconnect. So I'll restrict this issue to that. Once that is resolved, we can see if there are still any defect behavior in docker. |
|
I digged a bit in the code and found that for me it happened on my log: https://pastebin.com/1cJhhnXb |
* Fix SIGSEGV panic in issue andersfylling#298, function returns non-nil error: "context cancelled" * Fix opCode 3 sending before opCode 0 in voice * this caused "authentication error", which resulted in SIGSEGV * Add & improved errors and logs in (re)connecting functions
* Fix SIGSEGV panic in issue andersfylling#298, function returns non-nil error: "context cancelled" * Fix opCode 3 sending before opCode 0 in voice * this caused "authentication error", which resulted in SIGSEGV * Add & improved errors and logs in (re)connecting functions
* Fix SIGSEGV panic in issue andersfylling#298, function returns non-nil error: "context cancelled" * Fix opCode 3 sending before opCode 0 in voice * this caused "authentication error", which resulted in SIGSEGV * Add & improved errors and logs in (re)connecting functions
* Fix SIGSEGV panic in issue andersfylling#298, function returns non-nil error: "context cancelled" * Fix opCode 3 sending before opCode 0 in voice * this caused "authentication error", which resulted in SIGSEGV * Add & improved errors and logs in (re)connecting functions
* Fix SIGSEGV panic in issue andersfylling#298, function returns non-nil error: "context cancelled" * Fix opCode 3 sending before opCode 0 in voice * this caused "authentication error", which resulted in SIGSEGV * Add & improved errors and logs in (re)connecting functions
|
@magnusfrater it seems @oidq have resolved the nil panic. If you can use the latest on the develop branch to further verify this that would be great. @oidq did mention a new issue though, that instead of the nil panic he sometimes got a auth issue. Regardless, it's a nice improvement and fixes the overall codeflow to be more accurate in accordance with the discord docs. |
|
These fixes seem to solve my issue. The only errors that show up now are these: But the fix for these might fall under a separate issue. |
* fix handling of error in nhooyr websocket wrapper (mentioned in andersfylling#298) * closing context given to g.c.Read(ctx) leads to WebSocket being closed coder/websocket#242
Describe the bug
I have written a bot to listen for a single command, connect to a voice channel, 'speak' into it, then leave. This is identical code to this repo's Connecting to Voice example (only this time with real error handling. Everything works fine in a local environment
The bug: When running this in a Docker container on a Digital Ocean droplet, there is a runtime error every single time without fail. I receive this exact error a few times during local development too, but very infrequently. In the production environment, it crashes everytime.
Expected behavior
I expect to listen for a command, and send the single
.dcaaudio through to a voice channel. Simple, just like the Connecting to Voice example.Error messages
Desktop (please complete the following information):
Additional context
Here is the relevant code. This should be identical to this repo's Connecting to Voice example, only this time with error handling.
The text was updated successfully, but these errors were encountered: