Open mitjastachowiak opened 6 years ago
jsamyth
commented
6 years ago Seeing same symptoms on Pidgin 2.13.0. Manjaro Linux. Can receive messages with omemo, but reply or sending caues Pigin to dump core. Toggle off Lurch, and it works. Lurch 0.6.7 from Archlinux AUR. No solution found yet.
gkdr
commented
6 years ago I was about to ask if you're on < 2.10.10, because I set the message to NULL to prevent sending it until the sessions between all devices have been established and a missing NULL check on older version causes a segfault. But since it happens with 2.13.0 too, there might have been another change that broke what I'm doing. I'm still developing against 2.11.0, I'll try to upgrade and see what happens.
If it is what I'm thinking, this should only happen if Pidgin needs to establish a session, a temporary workaround might be to have the other device establish it by sending a message. It might be all of yours and your conversation partner's, so I don't know how viable it is in your case.
By the way, as it should be compiled with debugging symbols if the makefile was not modified, you should be able to run it through gdb - a stack trace would probably help.
jsamyth
commented
6 years ago Systemd did give me a stack trace, My gdb skills ran screaming for the exit years ago.
`May 02 11:53:35 ScreenioGate systemd-coredump[11035]: Process 10499 (pidgin) of user 1000 dumped core.
Stack trace of thread 10499:
#0 0x00007fd9ea00c860 raise (libc.so.6)
#1 0x00007fd9ea00dec9 abort (libc.so.6)
#2 0x000055da50bdbfdd n/a (pidgin)
#3 0x00007fd9ea3a0dd0 __restore_rt (libpthread.so.0)
#4 0x00007fd9d0c19c65 jabber_send_signal_cb (libjabber.so.0)
#5 0x00007fd9ea989d3a purple_signal_emit_vargs (libpurple.so.0)
#6 0x00007fd9ea989eaf purple_signal_emit (libpurple.so.0)
#7 0x00007fd9d0c17c34 jabber_send (libjabber.so.0)
#8 0x00007fd9d0c29d2e jabber_message_send (libjabber.so.0)
#9 0x00007fd9d0c29f66 jabber_message_send_im (libjabber.so.0)
#10 0x00007fd9ea9879ec serv_send_im (libpurple.so.0)
#11 0x00007fd9ea951a8c n/a (libpurple.so.0)
#12 0x000055da50baa765 n/a (pidgin)
#13 0x00007fd9eaf5fa4d g_closure_invoke (libgobject-2.0.so.0)
#14 0x00007fd9eaf729d3 n/a (libgobject-2.0.so.0)
#15 0x00007fd9eaf7b6f6 g_signal_emit_valist (libgobject-2.0.so.0)
#16 0x00007fd9eaf7c60c g_signal_emit_by_name (libgobject-2.0.so.0)
#17 0x00007fd9eaf5fa4d g_closure_invoke (libgobject-2.0.so.0)
#18 0x00007fd9eaf72e40 n/a (libgobject-2.0.so.0)
#19 0x00007fd9eaf7b6f6 g_signal_emit_valist (libgobject-2.0.so.0)
#20 0x00007fd9eaf7c130 g_signal_emit (libgobject-2.0.so.0)
#21 0x00007fd9ebe92895 n/a (libgtk-x11-2.0.so.0)
#22 0x00007fd9eaf5fa4d g_closure_invoke (libgobject-2.0.so.0)
#23 0x00007fd9eaf72f18 n/a (libgobject-2.0.so.0)
#24 0x00007fd9eaf7b6f6 g_signal_emit_valist (libgobject-2.0.so.0)
#25 0x00007fd9eaf7c130 g_signal_emit (libgobject-2.0.so.0)
#26 0x00007fd9ebe917ba n/a (libgtk-x11-2.0.so.0)
#27 0x00007fd9ebf3a7cc n/a (libgtk-x11-2.0.so.0)
#28 0x00007fd9eaf5fa4d g_closure_invoke (libgobject-2.0.so.0)
#29 0x00007fd9eaf72bca n/a (libgobject-2.0.so.0)
#30 0x00007fd9eaf7b081 g_signal_emit_valist (libgobject-2.0.so.0)
#31 0x00007fd9eaf7c130 g_signal_emit (libgobject-2.0.so.0)
#32 0x00007fd9ec055235 n/a (libgtk-x11-2.0.so.0)
#33 0x00007fd9ebf38a0e gtk_propagate_event (libgtk-x11-2.0.so.0)
#34 0x00007fd9ebf38e43 gtk_main_do_event (libgtk-x11-2.0.so.0)
#35 0x00007fd9ebbb1d5e n/a (libgdk-x11-2.0.so.0)
#36 0x00007fd9eac85368 g_main_context_dispatch (libglib-2.0.so.0)
#37 0x00007fd9eac855b1 n/a (libglib-2.0.so.0)
#38 0x00007fd9eac858e2 g_main_loop_run (libglib-2.0.so.0)
#39 0x00007fd9ebf37df3 gtk_main (libgtk-x11-2.0.so.0)
#40 0x000055da50b863cd main (pidgin)
#41 0x00007fd9e9ff8f4a __libc_start_main (libc.so.6)
#42 0x000055da50b866ca _start (pidgin)
Stack trace of thread 10502:
#0 0x00007fd9ea0c397b __poll (libc.so.6)
#1 0x00007fd9eac85523 n/a (libglib-2.0.so.0)
#2 0x00007fd9eac8563e g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007fd9eac85692 n/a (libglib-2.0.so.0)
#4 0x00007fd9eacada2a n/a (libglib-2.0.so.0)
#5 0x00007fd9ea39608c start_thread (libpthread.so.0)
#6 0x00007fd9ea0cde7f __clone (libc.so.6)
Stack trace of thread 10503:
#0 0x00007fd9ea0c397b __poll (libc.so.6)
#1 0x00007fd9eac85523 n/a (libglib-2.0.so.0)
#2 0x00007fd9eac858e2 g_main_loop_run (libglib-2.0.so.0)
#3 0x00007fd9e83af348 n/a (libgio-2.0.so.0)
#4 0x00007fd9eacada2a n/a (libglib-2.0.so.0)
#5 0x00007fd9ea39608c start_thread (libpthread.so.0)
#6 0x00007fd9ea0cde7f __clone (libc.so.6)
Stack trace of thread 10501:
#0 0x00007fd9ea0c57b3 __select (libc.so.6)
#1 0x00007fd9d3bbac2d NotifierThreadProc (libtcl8.6.so)
#2 0x00007fd9ea39608c start_thread (libpthread.so.0)
#3 0x00007fd9ea0cde7f __clone (libc.so.6)
Stack trace of thread 10506:
#0 0x00007fd9ea0c397b __poll (libc.so.6)
#1 0x00007fd9cc7f0773 n/a (libpulse.so.0)
#2 0x00007fd9cc7e1bd0 pa_mainloop_poll (libpulse.so.0)
#3 0x00007fd9cc7e2271 pa_mainloop_iterate (libpulse.so.0)
#4 0x00007fd9cc7e2301 pa_mainloop_run (libpulse.so.0)
#5 0x00007fd9cc7f06ae n/a (libpulse.so.0)
#6 0x00007fd9cc58f81c n/a (libpulsecommon-11.1.so)
#7 0x00007fd9ea39608c start_thread (libpthread.so.0)
#8 0x00007fd9ea0cde7f __clone (libc.so.6)`
gkdr
commented
6 years ago @mitjastachowiak Which version of libpurple are you using? Sorry, I somehow missed the second question: If you can live with an annoying error (which is probably better than the program crashing), you can just add the conversation to the blacklist by typing /lurch blacklist add. You will still be able to receive encrypted messages.
@jsamyth I dug out some other system to test it on, but was not able to reproduce this on Fedora 26 with Pidgin/libpurple 2.13.0, so it must be something other than just the libpurple version. If you just run pidgin through gdb by typing gdb pidgin and then just run once inside, you can type bt after it crashes to get a stack trace that should contain a bit more information.
jsamyth
commented
6 years ago @gkdr I've run the requested test, and pasted the results below.
Note that I can send messages to this instance of pidgin from Conversations, but any attempt to send from Pidgin to Conversations instantly crashes Pigin. (and the message does not get sent.).
Sending to a recipient that is not using OMEMO does not crash, and works fine.
Sending to Pidin on windows 10 (Version 2.12.0 using libpurple 2.12.0) also works fine in both directions with OMEMO.
Again, the crashing pidgin is via Manjaro repositories Pidgin 2.13.0 (libpurple 2.13.0), and it only crashes on send.
`Thread 1 "pidgin" received signal SIGSEGV, Segmentation fault. 0x00007fffdb22ec65 in jabber_send_signal_cb () from /usr/lib/purple-2/libjabber.so.0 (gdb) bt
(gdb) `
mitjastachowiak
commented
6 years ago In the libertine-container, dpgk -s libpurple tells me, that this package is not installed. There is an other problem with Libertine: The power consumption is very high while libertine is running, so the battery is empty after 2 hours.
jsamyth
commented
6 years ago @gkdr:
Regarding my debug log above, and my posting on this thread, I'd recommend you not spend time on my stack trace with regard to this thread.
I believe my problem was actually related to Issue #56. I've posted on that issue, but won't repost the above stack trace under #56.
Hello, I'm using Pidgin+lurch in an libertine-container on my ubuntu touch. I can receive encrypted messages, but when I answer, pidgin crashes. No hint found in the logfiles. If lurch is disabled, it works.
For a fast workaround: which file do I need to modify, to prevent lurch from encrypting messages? There must be some event triggered by pidgin, which lets lurch suspend the sending process and encrypt the message.