sleepy-discord
sleepy-discord copied to clipboard
yourWaifu
Crash on quit
I downloaded the latest from the Develop branch and now it crashes on quit().
[2018-05-29 02:17:53] [warning] got non-close frame while closing [2018-05-29 02:17:53] [warning] got non-close frame while closing [2018-05-29 02:17:53] [error] handle_read_frame error: asio.ssl.stream:1 (stream truncated) [2018-05-29 02:17:53] [info] asio async_shutdown error: asio.ssl.stream:1 (stream truncated) [2018-05-29 02:17:53] [disconnect] Disconnect close local:[1006,stream truncated] remote:[1000]
It's hard to say what's causing the crash. What I can see is that it looks like you are using mode USE_RUN_THREAD. Which to be honest, I haven't used in like forever. The run thread is used for scheduling events and websocket connections. I'm not sure if you really need this thread but try using USER_CONTROLED_THREADS, do not that this isn't documented just yet but the example have already been updated if you need examples.
I dont need any threads I didn't change anything. I clicked build on visual studio after downloading develop.
Unless you mean this https://github.com/Brandantl/Monero-TipBot/blob/master/src/main.cpp#L120
Which I copied and paste from an example I think
change
TIPBOT client(GlobalConfig.General.discordToken, 2);
to
TIPBOT client(GlobalConfig.General.discordToken, SleepyDiscord::USER_CONTROLED_THREADS);
Sorry about this, I noticed that a number of users were getting confused about the number so I changed it. I must of changed to the number to better represent how many threads are actually being used.
I'll document this change in the docs. Thanks for reminding me.
I just reverted to the last known working version I had compiled. It's broken on the most recent sleepy discord though.
I have actually recently ran into this issue, it seems to happen randomly on a bad connection. This one is going to a hard issue to debug if that's the case.
So the quit() is functioning correctly but when the class destructs afterwards it crashes in the WebsocketppDiscordClient destructor.
We cleanly exited the sleepy discord run() function here (which is what Tbot.start(); does)
I think there is an issue with the order in which the destructors are working or that _thread isn't being set to nullptr after quit() is invoked and the threads are shutdown. It reads 0xcccccccc
(((SleepyDiscord::WebsocketppDiscordClient)&(((Discord)&Tbot))))._thread
is NEVER initialized in the life time of the application.
That's your issue. _threads is never initialized to nullptr therefore undefined behavior occurs on shutdown.
actually that makes sense, most of the time, it does nothing unless you asked for more threads. I can't remember why reset is being called since that was written so long ago.
This still exists and is kind of annoying because I need my bot to clean exit on shutdown.
It does it now on Linux and Windows and only when sleepy discord is enabled.
Even crashes on exit with this code
Attached to this comment is the compilable code. Discord-Test.zip
I'm actually currently making some changes to quit that should hopefully fix this issue. I think it should be finished by tomorrow.
No problem I was trying to find it using my commercial memory checkers and couldn't locate it for some reason. I'll check with valgrind to see if i can pinpoint it.
Nope couldn't figure it out. I'll test it again once you refactor quit() and the shutdown process.
Stack corruption still occurs on https://github.com/yourWaifu/sleepy-discord/commit/325e770b2eb6602a8312b38bff6ba6e099b307dd
I did some testing and found that adding the predecessor define SLEEPY_VOICE_ENABLED fixes this, and this is why I wasn't getting this error. I'll see what SLEEPY_VOICE_ENABLED has to do with this issue.
G++ won't allow you to compile because of a local being returned from a reference function.
you can remove that function, it's not used nor does it work. I also thought I removed it.
The issue still occurs on builds without SLEEPY_VOICE_ENABLED
and this happens with SLEEPY_VOICE_ENABLED
Yup I can confirm now that SLEEPY_VOICE_ENABLED compiles that it does not occur with that define. I'll test it on Windows in a bit to see if that CRT error still occurs.
