Profanity: Profanity is crashing after login

[mdosch]

Update: I also checked with Debian Stable (Buster / 10) and it also crashes there. The backtrace is linked in Current Behavior too.

After upgrading to current master build profanity is crashing after login.

Expected Behavior

It should not crash.

Current Behavior

It crashes immediately after logging in to the xmpp account.
gdb bt full
gdb bt full - Debian Stable

Environment

OS: Debian SID

uname -a
Linux schlepptop 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux

profanity --version
Profanity, version 0.6.0dev.master.63552720
Copyright (C) 2012 - 2019 James Booth <[email protected]>.
Copyright (C) 2019 Michael Vetter <[email protected]>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libstrophe
Desktop notification support: Enabled
OTR support: Disabled
PGP support: Enabled (libgpgme 1.12.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (2.7.16)
GTK icons: Enabled



md5-82ca5680d81b1953e749a77a91cf32c8



Prosody hg:08c6540f5a65

# Prosody directories
Data directory:     /home/md85/var/lib/prosody
Config directory:   /home/md85/etc/prosody
Source directory:   /home/md85/lib/prosody
Plugin directories:
  /home/md85/opt/prosody-modules/
  /home/md85/lib/prosody/modules/


# Operating system
Linux 2.6.32-754.15.3.el6.x86_64    

# Lua environment
Lua version:                Lua 5.2

Lua module search paths:
  /home/md85/lib/prosody/?.lua
  /home/md85/.luarocks/share/lua/5.2/?.lua
  /home/md85/.luarocks/share/lua/5.2/?/init.lua
  /home/md85/share/lua/5.2/?.lua
  /home/md85/share/lua/5.2/?/init.lua

Lua C module search paths:
  /home/md85/lib/prosody/?.so
  /home/md85/.luarocks/lib/lua/5.2/?.so
  /home/md85/lib/lua/5.2/?.so

LuaRocks:           Installed (2.4.3)

# Network

Backend: libevent epoll

# Lua module versions
lfs:        LuaFileSystem 1.7.0
libevent:   2.1.8-stable
luaevent:   0.4.6
lxp:        LuaExpat 1.3.3
socket:     LuaSocket 3.0-rc1
ssl:        0.8

[jubalh]

Maybe there is a mistake in https://github.com/profanity-im/profanity/commit/9aad2aa4878fffec098e8b2ecf382be565bd44a7

@mdosch can you try the commit before that?

[pmaziere]

I confirm this crash
rolling back to 46ecdc33 makes profanity usable again

[jubalh]

Thanks for confirming. I'll work on a fix as soon as I have time (and understand the problem) :-)

[jubalh]

One step closer with: https://github.com/profanity-im/profanity/pull/1149
Now another double free at:

#0  0x00007ffff6b66dd1 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff6b50549 in __GI_abort () at abort.c:79
#2  0x00007ffff6ba961f in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff6cb5ab9 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff6bafd9c in malloc_printerr (str=str@entry=0x7ffff6cb7738 "free(): double free detected in tcache 2") at malloc.c:5356
#4  0x00007ffff6bb1755 in _int_free (av=0x7ffff6ce8aa0 <main_arena>, p=0x7a9670, have_lock=<optimized out>) at malloc.c:4213
#5  0x00000000004ae901 in omemo_key_free (key=0x7a41c0) at src/omemo/omemo.c:1305
#6  0x00000000004b16bc in omemo_start_device_session_handle_bundle (stanza=0x799b60, userdata=0x797810) at src/xmpp/omemo.c:171
#7  0x000000000043405f in _iq_handler (conn=0xe9cad0, stanza=0x799b60, userdata=0xeee150) at src/xmpp/iq.c:215
#8  0x00007ffff6d1b18f in handler_fire_stanza (conn=conn@entry=0xe9cad0, stanza=stanza@entry=0x799b60) at src/handler.c:124
#9  0x00007ffff6d17bdb in _handle_stream_stanza (stanza=0x799b60, userdata=0xe9cad0) at src/conn.c:1253
#10 0x00007ffff6d2443f in _end_element (userdata=0xea3300, name=<optimized out>) at src/parser_expat.c:190
#11 0x00007ffff5fe0aa5 in doContent
    (parser=parser@entry=0xeef800, startTagLevel=startTagLevel@entry=0, enc=<optimized out>, s=<optimized out>, end=<optimized out>, nextPtr=0xeef830, haveMore=1 '\001') at xmlparse.c:2977
#12 0x00007ffff5fe23ac in contentProcessor (parser=0xeef800, start=<optimized out>, end=<optimized out>, endPtr=<optimized out>) at xmlparse.c:2552
#13 0x00007ffff5fe57ec in XML_ParseBuffer (isFinal=0, len=<optimized out>, parser=0xeef800) at xmlparse.c:1988
#14 0x00007ffff5fe57ec in XML_ParseBuffer (parser=0xeef800, len=<optimized out>, isFinal=0) at xmlparse.c:1957
#15 0x00007ffff6d1aa64 in xmpp_run_once (ctx=0xeee150, timeout=10) at src/event.c:255
#16 0x0000000000432e5e in connection_check_events () at src/xmpp/connection.c:104
#17 0x00000000004323b4 in session_process_events () at src/xmpp/session.c:255
#18 0x000000000042c098 in prof_run (log_level=0x4d9e10 "INFO", account_name=0x0) at src/profanity.c:128
#19 0x00000000004b25e2 in main (argc=1, argv=0x7fffffffdb18) at src/main.c:172

[jubalh]

Another:

#0  0x00007ffff6b66dd1 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff6b50549 in __GI_abort () at abort.c:79
#2  0x00007ffff6ba961f in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff6cb5ab9 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff6bafd9c in malloc_printerr (str=str@entry=0x7ffff6cb3c4b "free(): invalid size") at malloc.c:5356
#4  0x00007ffff6bb150c in _int_free (av=<optimized out>, p=0x4d3ea40, have_lock=<optimized out>) at malloc.c:4189
#5  0x00000000004395e6 in _iq_free_room_data (roominfo=0xedb0f0) at src/xmpp/iq.c:2457
#6  0x00000000004341bd in _iq_id_handler_free (handler=0xed2350) at src/xmpp/iq.c:259
#7  0x00007ffff72f95a4 in  () at /usr/lib64/libglib-2.0.so.0
#8  0x000000000043407e in _iq_handler (conn=0xe32600, stanza=0x4d3ddb0, userdata=0xe8a7c0) at src/xmpp/iq.c:217
#9  0x00007ffff6d1b18f in handler_fire_stanza (conn=conn@entry=0xe32600, stanza=stanza@entry=0x4d3ddb0) at src/handler.c:124
#10 0x00007ffff6d17bdb in _handle_stream_stanza (stanza=0x4d3ddb0, userdata=0xe32600) at src/conn.c:1253
#11 0x00007ffff6d2443f in _end_element (userdata=0xe682f0, name=<optimized out>) at src/parser_expat.c:190
#12 0x00007ffff5fe0aa5 in doContent
    (parser=parser@entry=0xe8dc00, startTagLevel=startTagLevel@entry=0, enc=<optimized out>, s=<optimized out>, end=<optimized out>, nextPtr=0xe8dc30, haveMore=1 '\001') at xmlparse.c:2977
#13 0x00007ffff5fe23ac in contentProcessor (parser=0xe8dc00, start=<optimized out>, end=<optimized out>, endPtr=<optimized out>) at xmlparse.c:2552
#14 0x00007ffff5fe57ec in XML_ParseBuffer (isFinal=0, len=<optimized out>, parser=0xe8dc00) at xmlparse.c:1988
#15 0x00007ffff5fe57ec in XML_ParseBuffer (parser=0xe8dc00, len=<optimized out>, isFinal=0) at xmlparse.c:1957
#16 0x00007ffff6d1aa64 in xmpp_run_once (ctx=0xe8a7c0, timeout=10) at src/event.c:255
#17 0x0000000000432e5e in connection_check_events () at src/xmpp/connection.c:104
#18 0x00000000004323b4 in session_process_events () at src/xmpp/session.c:255
#19 0x000000000042c098 in prof_run (log_level=0x4d9e10 "INFO", account_name=0x0) at src/profanity.c:128
#20 0x00000000004b25fc in main (argc=1, argv=0x7fffffffda88) at src/main.c:172

[jubalh]

@mdosch I merged the PR. Please give master a try and let us know if it works for you.
It does for me.

[mdosch]

Unfortunately it doesn't change the behavior for me: bt full.
Would be interesting to know if profanity also still crashes for @pmaziere

[vacuumbeef]

Still crashes for me too

[mdosch]

With the latest commits it still crashes for me too bt full

[pmaziere]

eb14ae5f03f8dcc013956b9f3367c6c90700c3ff works fine here, no crash

[vacuumbeef]

Same, no crashes now.

[pasis]

There are multiple places where crashes still will happen. Pattern of the problem is that every specific id handler frees own userdata. It is not the right way to do so. @jubalh made the proper solution via common destructor, but now, every id handler needs to be fixed.

As an example, look at _caps_response_for_jid_id_handler(). Userdata for this handler is jid:

char *jid = (char *)userdata;

And the function frees it below in several places. But on the other hand, there is interface iq_id_handler_add() which accepts pointer to the destructor which must free the userdata. This is where double free issue comes from. So the solution is to remove all free(jid) from the handler. And the same needs to be done for every handler.

[jubalh]

Thanks @pasis! I tried to adress this in above mentioned commit. That should be all, right? Would be good if someone could confirm.

@mdosch , @vacuumbeef , @pmaziere ok I hope all works now! Feedback welcome! And give it some heavy testing ;-)

[mdosch]

I did no extensive testing yet but Version 0.6.0dev.master.ad41959c doesn't crash after connect and I was already able to write to a MUC so it looks good now. :)
Thank you all for your efforts!

[mdosch]

I am closing this issue as no more crashes after login appeared after several starts.