I restarted my server and after profanity automatically reconnected it crashed with a segfault.
Backtraces: bt, bt-full
No segfault.
Segfault.
Profanity, version 0.6.0dev.master.c07d533e
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
prosodyctl about
Prosody hg:a36c731ed540
# 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: 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
When I am connected via profanity and stop prosody I get:
Program received signal SIGPIPE, Broken pipe.
0x00007ffff6cff311 in __libc_write (fd=9, buf=0xe01923, nbytes=236) at ../sysdeps/unix/sysv/linux/write.c:26
26 return SYSCALL_CANCEL (write, fd, buf, nbytes);
gdb$ bt
#0 0x00007ffff6cff311 in __libc_write (fd=9, buf=0xe01923, nbytes=236) at ../sysdeps/unix/sysv/linux/write.c:26
#1 0x00007ffff67a2615 in () at /usr/lib64/libcrypto.so.1.1
#2 0x00007ffff679da4a in () at /usr/lib64/libcrypto.so.1.1
#3 0x00007ffff679caa4 in () at /usr/lib64/libcrypto.so.1.1
#4 0x00007ffff679cf63 in BIO_write () at /usr/lib64/libcrypto.so.1.1
#5 0x00007ffff69de076 in () at /usr/lib64/libssl.so.1.1
#6 0x00007ffff69def69 in () at /usr/lib64/libssl.so.1.1
#7 0x00007ffff69df1b5 in () at /usr/lib64/libssl.so.1.1
#8 0x00007ffff69f19f5 in () at /usr/lib64/libssl.so.1.1
#9 0x00007ffff69f1b23 in SSL_write () at /usr/lib64/libssl.so.1.1
#10 0x00007ffff6d220a3 in tls_write (tls=0xdea400, buff=<optimized out>, len=len@entry=207) at src/tls_openssl.c:462
#11 0x00007ffff6d18483 in xmpp_run_once (ctx=0xdf34c0, timeout=10) at src/event.c:104
#12 0x0000000000432e97 in connection_check_events () at src/xmpp/connection.c:104
#13 0x00000000004323ed in session_process_events () at src/xmpp/session.c:255
#14 0x000000000042c0a8 in prof_run (log_level=0x4d9e10 "INFO", account_name=0x0) at src/profanity.c:128
#15 0x00000000004b2484 in main (argc=1, argv=0x7fffffffdb18) at src/main.c:172
Weird, I don't get SIGPIPE when stopping prosody but a segfault SIGSEGV when restarting prosody:
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x00007ffff66f3dae in __GI___strdup (s=0x0) at strdup.c:41
#2 0x00005555555b1170 in _create_tab (win=16, wintype=WIN_CHAT, identifier=0x5555578b5160 "mdosch.de", highlight=1)
at src/ui/statusbar.c:201
#3 0x00005555555b122d in status_bar_new (win=16, wintype=WIN_CHAT, identifier=0x5555578b5160 "mdosch.de")
at src/ui/statusbar.c:224
#4 0x00005555555c1884 in chatwin_incoming_msg (chatwin=0x555557fa4970, message=0x555559b47e90, win_created=1)
at src/ui/chatwin.c:267
#5 0x00005555555a4da8 in _sv_ev_incoming_plain (chatwin=0x555557fa4970, new_win=1, message=0x555559b47e90)
at src/event/server_events.c:572
#6 0x00005555555a4eaa in sv_ev_incoming_message (message=0x555559b47e90) at src/event/server_events.c:686
#7 0x0000555555597df7 in _handle_chat (stanza=0x5555569b6080) at src/xmpp/message.c:1100
#8 0x0000555555595bf2 in _message_handler (conn=0x55555699fcd0, stanza=0x5555569b6080, userdata=0x55555af1feb0)
at src/xmpp/message.c:153
#9 0x00007ffff685cca5 in ?? () from target:/usr/lib/x86_64-linux-gnu/libstrophe.so.0
#10 0x00007ffff685995a in ?? () from target:/usr/lib/x86_64-linux-gnu/libstrophe.so.0
#11 0x00007ffff686570f in ?? () from target:/usr/lib/x86_64-linux-gnu/libstrophe.so.0
#12 0x00007ffff4a5a9f6 in ?? () from target:/lib/x86_64-linux-gnu/libexpat.so.1
#13 0x00007ffff4a5b49c in ?? () from target:/lib/x86_64-linux-gnu/libexpat.so.1
#14 0x00007ffff4a5d9f8 in XML_ParseBuffer () from target:/lib/x86_64-linux-gnu/libexpat.so.1
#15 0x00007ffff685c5dc in xmpp_run_once () from target:/usr/lib/x86_64-linux-gnu/libstrophe.so.0
#16 0x000055555558f0ca in connection_check_events () at src/xmpp/connection.c:104
#17 0x000055555558e5eb in session_process_events () at src/xmpp/session.c:255
#18 0x0000555555587fac in prof_run (log_level=0x555555635160 "INFO", account_name=0x0) at src/profanity.c:128
#19 0x000055555560f834 in main (argc=1, argv=0x7fffffffe268) at src/main.c:172
Due to the line #2 0x00005555555b1170 in _create_tab (win=16, wintype=WIN_CHAT, identifier=0x5555578b5160 "mdosch.de", highlight=1) I suspect it happens when my server mdosch.de sends me the message about failed s2s to conference.torservers.net after a restart:
Establishing a secure connection from mdosch.de to conference.torservers.net failed. Certificate hash: 5010a42e638631181becc8860be14e29aae9a173a22fb8f6350592f2fd716f56. This certificate is invalid for conference.torservers.net.
This message is created by the prosody module watchuntrusted.
I'm sorry for the failed formatting in my earlier comment. I wasn't aware of Github not supporting markdown for email replies...
I realized that I was missing some debug symbols so here is another backtrace:
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x00007ffff66f3dae in __GI___strdup (s=0x0) at strdup.c:41
#2 0x00005555555b1170 in _create_tab (win=16, wintype=WIN_CHAT, identifier=0x55555bd57010 "mdosch.de", highlight=1)
at src/ui/statusbar.c:201
#3 0x00005555555b122d in status_bar_new (win=16, wintype=WIN_CHAT, identifier=0x55555bd57010 "mdosch.de")
at src/ui/statusbar.c:224
#4 0x00005555555c1884 in chatwin_incoming_msg (chatwin=0x555559a9ca40, message=0x55555a7df9a0, win_created=1)
at src/ui/chatwin.c:267
#5 0x00005555555a4da8 in _sv_ev_incoming_plain (chatwin=0x555559a9ca40, new_win=1, message=0x55555a7df9a0)
at src/event/server_events.c:572
#6 0x00005555555a4eaa in sv_ev_incoming_message (message=0x55555a7df9a0) at src/event/server_events.c:686
#7 0x0000555555597df7 in _handle_chat (stanza=0x55555ae740e0) at src/xmpp/message.c:1100
#8 0x0000555555595bf2 in _message_handler (conn=0x555555d5fc00, stanza=0x55555ae740e0, userdata=0x5555557841a0)
at src/xmpp/message.c:153
#9 0x00007ffff685cca5 in handler_fire_stanza (conn=conn@entry=0x555555d5fc00, stanza=stanza@entry=0x55555ae740e0)
at src/handler.c:124
#10 0x00007ffff685995a in _handle_stream_stanza (stanza=0x55555ae740e0, userdata=0x555555d5fc00) at src/conn.c:1179
#11 0x00007ffff686570f in _end_element (userdata=0x55555ae65fa0, name=<optimized out>) at src/parser_expat.c:190
#12 0x00007ffff4a5a9f6 in doContent (parser=parser@entry=0x555555c4a9c0, startTagLevel=startTagLevel@entry=0,
enc=<optimized out>, s=<optimized out>,
end=0x55555628dcfe "e='participant' affiliation='none'/></x></presence>ity.eiM4wu' xml:lang='en'><show>away</show><status> (Away as a result of being idle more than 5 min)</status><x xmlns='vcard-temp:x:update'><photo>57"...,
--Type <RET> for more, q to quit, c to continue without paging--
nextPtr=0x555555c4a9f0, haveMore=1 '\001') at ../../src/lib/xmlparse.c:2977
#13 0x00007ffff4a5b49c in contentProcessor (parser=0x555555c4a9c0, start=<optimized out>, end=<optimized out>,
endPtr=<optimized out>) at ../../src/lib/xmlparse.c:2552
#14 0x00007ffff4a5d9f8 in XML_ParseBuffer (isFinal=0, len=673, parser=0x555555c4a9c0) at ../../src/lib/xmlparse.c:1988
#15 XML_ParseBuffer (parser=0x555555c4a9c0, len=673, isFinal=0) at ../../src/lib/xmlparse.c:1957
#16 0x00007ffff685c5dc in xmpp_run_once (ctx=0x5555557841a0, timeout=10) at src/event.c:263
#17 0x000055555558f0ca in connection_check_events () at src/xmpp/connection.c:104
#18 0x000055555558e5eb in session_process_events () at src/xmpp/session.c:255
#19 0x0000555555587fac in prof_run (log_level=0x555555635160 "INFO", account_name=0x0) at src/profanity.c:128
#20 0x000055555560f834 in main (argc=1, argv=0x7fffffffe4b8) at src/main.c:172
Wasn't it possible to just edit your previous comment (which you created via email) and then GH uses the right formatting?
Unfortunately it seems like editing doesn't help.
@mdosch could you post debug logs or just the full stanza that causes the crash? To get debug logs you need to run Profanity as profanity -l DEBUG. Then check ~/.local/share/profanity/logs/profanity.log. Don't forget to remove sensitive information, like passwords, when you post logs.
It took me a while to reproduce as conference.torservers.net is down, so I don't get this message on startup. Right now it does not crash on startup anymore but trying to contact some servers with invalid certs I got an crash again. Although looking at the logs I am not sure if this is related.
Thread 1 "profanity" received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x00007ffff66f4dae in __GI___strdup (s=0x0) at strdup.c:41
#2 0x00005555555b1128 in _create_tab (win=19, wintype=WIN_CHAT, identifier=0x555558018ea0 "mdosch.de", highlight=1)
at src/ui/statusbar.c:201
#3 0x00005555555b11e5 in status_bar_new (win=19, wintype=WIN_CHAT, identifier=0x555558018ea0 "mdosch.de")
at src/ui/statusbar.c:224
#4 0x00005555555c183c in chatwin_incoming_msg (chatwin=0x55555930a890, message=0x5555594f7260, win_created=1)
at src/ui/chatwin.c:267
#5 0x00005555555a4d60 in _sv_ev_incoming_plain (chatwin=0x55555930a890, new_win=1, message=0x5555594f7260)
at src/event/server_events.c:572
#6 0x00005555555a4e62 in sv_ev_incoming_message (message=0x5555594f7260) at src/event/server_events.c:686
#7 0x0000555555597df7 in _handle_chat (stanza=0x55555a2489a0) at src/xmpp/message.c:1100
#8 0x0000555555595bf2 in _message_handler (conn=0x555558df6cd0, stanza=0x55555a2489a0, userdata=0x555555eacc80)
at src/xmpp/message.c:153
#9 0x00007ffff685dca5 in handler_fire_stanza (conn=conn@entry=0x555558df6cd0, stanza=stanza@entry=0x55555a2489a0)
at src/handler.c:124
#10 0x00007ffff685a95a in _handle_stream_stanza (stanza=0x55555a2489a0, userdata=0x555558df6cd0) at src/conn.c:1179
#11 0x00007ffff686670f in _end_element (userdata=0x55555b6171d0, name=<optimized out>) at src/parser_expat.c:190
#12 0x00007ffff4a5f9f6 in doContent (parser=parser@entry=0x555555dd4d80, startTagLevel=startTagLevel@entry=0,
enc=<optimized out>, s=<optimized out>,
end=0x555556369a58 "[email protected]/josh'><c ver='GQikuR4wCskYjdaGcomkq6+Fieo=' hash='sha-1' node='http://conversations.im' xmlns='http://jabber.org/protocol/caps'/><x xmlns='http://jabber.org/protocol/muc#us"...,
nextPtr=0x555555dd4db0, haveMore=1 '\001') at ../../src/lib/xmlparse.c:2968
#13 0x00007ffff4a6049c in contentProcessor (parser=0x555555dd4d80, start=<optimized out>, end=<optimized out>,
endPtr=<optimized out>) at ../../src/lib/xmlparse.c:2543
#14 0x00007ffff4a629f8 in XML_ParseBuffer (isFinal=0, len=377, parser=0x555555dd4d80) at ../../src/lib/xmlparse.c:1979
#15 XML_ParseBuffer (parser=0x555555dd4d80, len=377, isFinal=0) at ../../src/lib/xmlparse.c:1948
#16 0x00007ffff685d5dc in xmpp_run_once (ctx=0x555555eacc80, timeout=10) at src/event.c:263
#17 0x000055555558f0ca in connection_check_events () at src/xmpp/connection.c:104
#18 0x000055555558e5eb in session_process_events () at src/xmpp/session.c:255
#19 0x0000555555587fac in prof_run (log_level=0x5555556c1420 "DEBUG", account_name=0x0) at src/profanity.c:128
#20 0x000055555560f7ec in main (argc=1, argv=0x7fffffffe238) at src/main.c:172
@paulfariello again ProfMessage plain/body?
@mdosch , unfortunately, the log doesn't contain at least the last few lines that relates to the crash. With such a backtrace we should see a message stanza logged by libstrophe and Message stanza handler fired from Profanity. The crash happens because identifier in your case is mdosch.de and not not a jid with @. So the stanza which causes the crash would be helpful to understand what kind of message is not handled by Profanity.
Thanks for the clarification. I will try to set prosody log level to debug to gather the message created by that prosody module ( https://modules.prosody.im/mod_watchuntrusted.html ) but I can not promise I can do so today.
@pasis I managed to reproduce the crash by triggering this message and had debug logs enabled. The stanza looks like this:
Jul 22 18:39:30 c2s6ce4860 debug SEND: <message type='chat' from='mdosch.de' to='JID_REDACTED'><body>Establishing a secure connection from mdosch.de to REMOTE_SERVER_REDACTED failed. Certificate hash: b191beab37618dd5dee63c19af3cf0f11d94cc753eeece5e0a70344fae1fce01. Error with certificate 0: unable to get local issuer certificate, unable to verify the first certificate. </body><stanza-id by='JID_REDACTED' xmlns='urn:xmpp:sid:0' id='sIPATvfpAFyVmt5B'/></message>
Jul 22 18:39:30 c2s22bde00 debug SEND: <message type='chat' from='mdosch.de' to='JID_REDACTED'><body>Establishing a secure connection from mdosch.de to REMOTE_SERVER_REDACTED failed. Certificate hash: b191beab37618dd5dee63c19af3cf0f11d94cc753eeece5e0a70344fae1fce01. Error with certificate 0: unable to get local issuer certificate, unable to verify the first certificate. </body><stanza-id by='JID_REDACTED' xmlns='urn:xmpp:sid:0' id='sIPATvfpAFyVmt5B'/></message>
BTW, this is not a copy&paste failure as this message appears double in my log (see the different c2s IDs) but this is normal as I was logged in with one profanity and one conversations instance by that time.
All redacted JIDs are my own JID (in by: and in to:) in the format [email protected].
@mdosch , thanks for the info. Now it's clear why Profanity crashes (as I suspected, attribute from is not a complete JID). It looks like server sends an error message as ordinary chat message. Need to think how we can handle this situation properly.
@pasis, thanks for investigating. According to this lib mdosch.de would be a valid jid:
XMPP addresses, more often called"JID's" (Jabber ID's) for historical reasons, comprise three parts: The localpart represents a specific user account, the domainpart is the domain, host name, or IP address of a server hosting the account, and the resourcepart which represents a specific client connected to an account (eg. the users phone or a web browser). Only the domainpart is required, and together they are formatted like an email with the resourcepart appended after a forward slash. For example, the following are all valid JIDs:
[email protected]
[email protected]/phone-b5c93ded
example.net
I tried to find that definition in the RFCs but didn't succeed so far.
Edit:
I found it in RFC7622 3.2:
The domainpart is the primary identifier and is the only REQUIRED element of a JID (a mere domainpart is a valid JID).
Since this was there since a long time and restarting the server probably doesn't happen often, I'll defer this to 0.8.0 so that we can get 0.7.0 out.
@mdosch , you're right, a domain is a valid JID, what I meant is that Profanity's code expects that all message stanzas have from JID with @. And when it receives stanza from mdosh.de it crashes due to NULL pointer dereference.
One simple solution is to handle such a stanza like any other and create new window and use domain name as the username. In this case it will be the same as stanza from an unknown sender.
More complicated solution is to handle stanzas from account's server and print messages to 1st window (console). But this way still requires workaround for all other JIDs that don't contain @.
In case somebody has time to do this, I'm happy to accept a PR. Also for 0.7.0.
@pasis do you know the relevant code parts?
@jubalh, I think so, let me check it.
I've created pull request which may fix the issue (#1183). Please check it. Sorry for delay.
@pasis, thank you very much.
It works fine for me.
Thanks for fixing this @pasis ! :-)
Most helpful comment
I've created pull request which may fix the issue (#1183). Please check it. Sorry for delay.