TildeFriends crashes on Windows when talking to Manyverse #96
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
After syncing TildeFreinds 0.0.26 for a few minutes, I tried to post a mention of my TF identity from my local Manyverse:
%+/XUi/U/upCaWPpuDqvY7Ziz1tnyUny6XsMJoEy+iPM=.sha256
While drafting the post, Manyverse crashed and I had to restart it.
Then I wen to go find the post in TildeFriends. But its web UI had become very janky; I would click on things and the page would not really update. I refreshed the page but it didn't really help.
I went to look at its terminal window and it was spamming loads and loads of "Internal Error: Task is gone".
Then the terminal window went away and the server stopped responding, so I think TF crashed.
Instead of doing that, it should not do that.
After restarting and clicking around in the connections page connecting to things, the server stopped again with this exciting log:
I tried again, and it crashed again. Now there's a bunch of complaints about an encrypted message not being long enough, but I am beginning to suspect that this thing about
tun0
is actually the cause of the crash.I think the "InternalError" here is just it trying to decrypt every string ending in
.box
as if it is a private message for me, and complaining whenever a string that ends in.box
in anyone's feed is too short to be that, as if that's an internal error and not a problem with whoever's feed. So that's not the source of the crash.It might have something to do with talking to a local Manyverse and also being in a room with the same Manyverse? Or with a peer going away unexpectedly?
I started TildeFriends again and it seemed happy for several minutes when I told my local Manyverse to connect to it. Then I connected to the j-serve-something-or-other room and started trying to talk to SoapDog, which got me the complaints about tun0 again but didn't seem to crash it. Then I connected to the TildeFriends room, and my local Manyverse crashed, and then TildeFriends crashed. Here's the tail end of that log:
Yeah, your interpretation of the .box message is correct. There were some recent changes around that that left some unfortunate noise.
Nothing is actually jumping out at me in these logs as being actually concerning / the source of a crash.
I hardly ever run the Windows build. I just poked at it for a few minutes and wasn't able to get it to misbehave. I will try harder.
It would be nice to get the crash in a debugger, but I do not even know how/if that works with how this is built. Another thing I will explore.
I don't have like a signal number or anything either, because it's Windows.
Here are a few more logs, featuring such popular hits as
Sending to a NULL task.
andERROR: InternalError: Invoking a function that has been released.
. None of those are the last message though, so presumably it's just segfaulting in some new and exciting way.And here's a backtrace from MSYS2's GDB
Unfortunately it looks like it amounts to "I tried to do a task and then died.", because libuv is not really a stack-based thing.
"Task is gone" spam, followed by crashto TildeFriends crashes on Windows when talking to ManyverseI do have symbols for libuv though. Here's more libuv guts than anyone wants to look at:
We're working on task 4294967295 of 6 apparently in this loop, which is suspicious. The
pending_reqs_tail
linked list inloop
also appears to be excitingly circular.0xec37350
is an excellent memory address for a libuvreq
because it's not mapped.I don't think we're really on the 4 jillionth thing in the array, I think we're really on the item at index 2 which has a very similar memory address stored in it, when compared to the bad
req
.If
container_of
does something clever like going 0x20 bytes left, that could be how we got this exciting unmapped address forreq
.This smells a lot like https://github.com/libuv/libuv/issues/2016
But maybe this is all caused by me having it under GDB under MSYS2 (which might count as "cygwin") and isn't actually the same crash as the one I want to get rid of?
I believe the actual crash is now fixed. If you're inclined, you can grab the latest
tildefriends.standalone.exe
from the artifact here: https://dev.tildefriends.net/cory/tildefriends/actions/runs/367