Open mdillavou opened 7 months ago
Weird. What's the actual error? A SEGV? It looks like buf is still valid there (at least the first 4 bytes of it) -- can you make sure all 24 bytes of buf are readable (e.g. x/24c buf
)? If the connection were just closed, it should just return EBADF or something, not crash there. Unless there is some memory corruption, this does feel more likely a libpurple or even libc/kernel/arm/VM bug.
It looks like it received a SIGPIPE
Thread 1 "pidgin" received signal SIGPIPE, Broken pipe.
SIGPIPE is semi-expected (see https://developer.pidgin.im/wiki/GetABacktrace)
Run handle SIGPIPE nostop noprint
in gdb first
ok, it happened again, this is what gdb showed:
(gdb) handle SIGPIPE nostop noprint
Signal Stop Print Pass to program Description
SIGPIPE No No Yes Broken pipe
I was able to continue
and things were fine. I'm guessing this isn't the crash I normally see.
I am running a Linux VM on mac os. Suspending the laptop and unsuspending causes the host os to reconnect to the network, but the VM doesn't always seem to be aware of this. I believe that is what causes this issue (as I don't see this crash on my Linux desktop). It appears that the
ws->ssl_connection
still has a valid address, so it is possible the bug is actually in libpurple.I am running:
Here is a stack trace: