Crash in purple-websocket

[mdillavou]

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:

• Fedora 39 on aarch64
• libpurple-2.14.12-4.fc39.aarch64
• slack-libpurple commit 1cfcf6694c0813d9362d31291e48b54fea1318b2

Here is a stack trace:

0x0000fffff6962a34 in __libc_send (flags=0, len=24, buf=0xaaaaaba28390, fd=52) at ../sysdeps/unix/sysv/linux/send.c:28
Downloading source file /usr/src/debug/glibc-2.38-16.fc39.aarch64/socket/../sysdeps/unix/sysv/linux/send.c
28        return SYSCALL_CANCEL (sendto, fd, buf, len, flags, NULL, 0);                                                                                                           
(gdb) bt
#0  0x0000fffff6962a34 in __libc_send (flags=0, len=24, buf=0xaaaaaba28390, fd=52) at ../sysdeps/unix/sysv/linux/send.c:28
#1  __libc_send (fd=52, buf=buf@entry=0xaaaaaba28390, len=len@entry=24, flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/send.c:23
#2  0x0000ffffe56bca8c [PAC] in pt_Send (fd=0xaaaaaba0f0b0, buf=0xaaaaaba28390, amount=24, flags=0, timeout=4294967295) at ../../../../nspr/pr/src/pthreads/ptio.c:2002
#3  0x0000ffffe59dd338 [PAC] in ssl_DefSend (ss=ss@entry=0xaaaaaba51e40, buf=0xaaaaaba28390 "\027\003\003", len=24, flags=flags@entry=0) at ssldef.c:105
#4  0x0000ffffe59c633c [PAC] in ssl3_SendRecord (ss=ss@entry=0xaaaaaba51e40, cwSpec=cwSpec@entry=0x0, ct=ct@entry=ssl_ct_alert, pIn=0xffffffffc122 "", 
    pIn@entry=0xffffffffc120 "\001", nIn=0, nIn@entry=2, flags=flags@entry=0) at ssl3con.c:2588
#5  0x0000ffffe59c68ec [PAC] in SSL3_SendAlert (ss=ss@entry=0xaaaaaba51e40, level=level@entry=alert_warning, desc=desc@entry=close_notify) at ssl3con.c:2913
#6  0x0000ffffe59e28fc [PAC] in ssl_SecureClose (ss=0xaaaaaba51e40) at sslsecur.c:744
#7  0x0000ffffe5560e1c [PAC] in ssl_nss_close (gsc=0xaaaaaba2b330) at /usr/src/debug/pidgin-2.14.12-4.fc39.aarch64/libpurple/plugins/ssl/ssl-nss.c:512
#8  0x0000fffff735e7ec [PAC] in purple_ssl_close (gsc=0xaaaaaba2b330) at /usr/src/debug/pidgin-2.14.12-4.fc39.aarch64/libpurple/sslconn.c:247
#9  0x0000ffffe628fdec [PAC] in purple_websocket_abort (ws=0xaaaaaba504b0) at purple-websocket.c:72
#10 0x0000aaaaaab1b7e8 in pidgin_io_invoke (source=<optimized out>, condition=<optimized out>, data=<optimized out>)
    at /usr/src/debug/pidgin-2.14.12-4.fc39.aarch64/pidgin/gtkeventloop.c:73
#11 0x0000fffff6cd0350 [PAC] in g_main_dispatch (context=0xaaaaaac04290) at ../glib/gmain.c:3476
#12 g_main_context_dispatch_unlocked (context=0xaaaaaac04290) at ../glib/gmain.c:4284
#13 0x0000fffff6d2e75c [PAC] in g_main_context_iterate_unlocked.isra.0 (context=0xaaaaaac04290, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib/gmain.c:4349
#14 0x0000fffff6cd1aa4 [PAC] in g_main_loop_run (loop=0xaaaaab947cf0) at ../glib/gmain.c:4551
#15 0x0000fffff7959530 [PAC] in IA__gtk_main () at /usr/src/debug/gtk2-2.24.33-15.fc39.aarch64/gtk/gtkmain.c:1270
#16 0x0000aaaaaaae797c [PAC] in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/pidgin-2.14.12-4.fc39.aarch64/pidgin/gtkmain.c:947

[dylex]

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.

[mdillavou]

It looks like it received a SIGPIPE

Thread 1 "pidgin" received signal SIGPIPE, Broken pipe.

[EionRobb]

SIGPIPE is semi-expected (see https://developer.pidgin.im/wiki/GetABacktrace)

Run handle SIGPIPE nostop noprint in gdb first

[mdillavou]

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.