XMPP Receipts Plugin creates a double free segfault when stopping [Not Related to purple-gowhatsapp] #194
Comments
|
Thank you for the report. There has been a number of reports of this plug-in not working on Pidgin/libpurple 2.14.13. Can you downgrade to 2.14.12 to check if it is working with that version? I am already conversing with grim (the main maintainer of Pidgin) to gain some insights. Which distribution do you use? Are you building from source or are you using the provided nightly build? Note to self: This is not the |
|
I've confirmed that this is also
I'm using ArchLinux's repos. I am using a build from source version of purple-gowhatsapp with commit ID e1bb3af), I've tested both versions a bit ago today (first with a older pidgin only and later with an older libpurple too), but I forgot to publish the comment where the logs appeared, and the error was still the same, pidgin segfaulted. |
|
Today, I was unable to reproduce the issue on my Arch system (now with Pidgin 2.14.13). Of course, this test environment is pretty much empty. Can you check if the crash happens with a clean purple config directory ( |
|
Message ID: ***@***.***>
On Mon, 08 Apr 2024 13:35:57 -0700 Hermann Höhne ***@***.***> wrote:
Today, I was unable to reproduce the issue on my Arch system (now with Pidgin 2.14.13). Of course, this test environment is pretty much empty. Can you check if the crash happens with a clean purple config directory (`pidgin -d -c /temp/config` or something)?
Seems like yes, even without configuring the account, just by doing ^C on the command line I reproduced it, and created another core dump file.
```
#0 __pthread_kill_implementation (threadid=<optimized out>, ***@***.***=6, ***@***.***=0) at pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {125397078227632}}
ret = <optimized out>
#1 0x0000720c47231393 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x0000720c471e06c8 in __GI_raise ***@***.***=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x0000720c471c84b8 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {125397078229288, 96358532419584, 0, 0, 125397078224936, 39, 96358524923072, 140730300168744, 125397073768560, 0, 96358532400176, 125397078227464, 125397078017578, 22, 140730300168743, 140730300168752}}, sa_flags = 1212839137, sa_restorer = 0x7ffe538cf9d0}
#4 0x0000720c471c9395 in __libc_message_impl ***@***.***=0x720c473412ea "%s\n") at ../sysdeps/posix/libc_fatal.c:132
ap = {{gp_offset = 16, fp_offset = 2818473244, overflow_arg_area = 0x7ffe538cfa00, reg_save_area = 0x7ffe538cf990}}
fd = 2
iov = {{iov_base = 0x720c4733f06b, iov_len = 23}, {iov_base = 0x720c473412ec, iov_len = 1}, {iov_base = 0x410, iov_len = 96358525184656}, {iov_base = 0x200, iov_len = 0}, {iov_base = 0x410, iov_len = 96358525184640}, {iov_base = 0x210, iov_len = 125397058716070}, {iov_base = 0x57a3381e20a0, iov_len = 125397060012736}}
iovcnt = <optimized out>
total = <optimized out>
cp = <optimized out>
#5 0x0000720c4723b2a7 in malloc_printerr ***@***.***=0x720c4733f06b "free(): invalid pointer") at malloc.c:5772
#6 0x0000720c4723d5b4 in _int_free (av=<optimized out>, p=<optimized out>, ***@***.***=0) at malloc.c:4507
size = <optimized out>
fb = <optimized out>
#7 0x0000720c4723fe93 in __GI___libc_free (mem=<optimized out>) at malloc.c:3398
ar_ptr = <optimized out>
p = <optimized out>
err = 0
#8 0x0000720c47768b91 in g_slice_free_chain_with_offset (mem_size=24, mem_chain=<optimized out>, next_offset=8) at ../glib/glib/gslice.c:315
current = <optimized out>
slice = 0x0
#9 0x0000720c474e49da in purple_plugin_destroy () at /usr/lib/libpurple.so.0
#10 0x0000720c474e5451 in purple_plugins_destroy_all () at /usr/lib/libpurple.so.0
#11 0x0000720c474bfc11 in purple_core_quit () at /usr/lib/libpurple.so.0
#12 0x000057a337378dcc in ??? ()
#13 0x0000720c47747279 in g_main_dispatch (context=0x57a3379fb9b0) at ../glib/glib/gmain.c:3344
dispatch = 0x720c477a4da0 <g_io_unix_dispatch>
prev_source = 0x0
begin_time_nsec = 30792301164019
was_in_call = 0
user_data = 0x0
callback = 0x57a337378cd0
cb_funcs = 0x720c47838380 <g_source_callback_funcs>
cb_data = 0x57a3379fb940
need_destroy = <optimized out>
source = 0x57a3379fb8c0
current = 0x57a338184430
i = 0
__func__ = "g_main_dispatch"
#14 0x0000720c477a64ff in g_main_context_dispatch_unlocked (context=0x57a3379fb9b0) at ../glib/glib/gmain.c:4152
#15 g_main_context_iterate_unlocked.isra.0 (context=0x57a3379fb9b0, ***@***.***=1, ***@***.***=1, self=<optimized out>) at ../glib/glib/gmain.c:4217
max_priority = 2147483647
timeout = 699
some_ready = 1
nfds = 7
allocated_nfds = 7
fds = 0x57a3381843d0
begin_time_nsec = 30792301118393
#16 0x0000720c47747ea7 in g_main_loop_run (loop=0x57a338184350) at ../glib/glib/gmain.c:4419
self = <optimized out>
__func__ = "g_main_loop_run"
#17 0x0000720c47d38473 in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
#18 0x000057a33732796e in main ()
```
I have noticed this time the unloading this plugin message doesn't appear and happens before:
```
(HH:MM:SS) main: Unloading all plugins
free(): invalid pointer
```
As opposed to something like:
```
(HH:MM:SS) main: Unloading whatsmeow (I don't remember the format right now)
free(): invalid pointer
```
|
|
I am afraid – since I am unable to reproduce this issue on my machine – we will not find the cause for this issue. Ideally, we would have a debug build of libpurple on your machine. Then we can see where exactly in |
Should I try to build my own libpurple and preload it, so that the one from the system (pacman) doesn't get loaded? |
|
Good idea. As far as I can tell, you should be able to add |
|
|
Confirmed. I have no idea what is going on, though. On my system, this crash is shadowed by a segfault in gstreamer. I need to work around it. Even then, is happens only when gdb is attached and a break-point is set. I suspect an error in memory management exposing a nasty race-condition somewhere. This is a variant of the Can you build libpurple with this configuration? With the optimization disabled completely, we might find out where exactly in I am currently launching pidgin like this (working directory is the directory where the PKGBUILD is located): |
No And also, with this PKGCONFIG I should be able to more clearly reproduce other crashes I might sometimes find for pidgin/libpurple's issue tracker, right? |
|
I just noticed that when I launch pidgin when there's another pidgin running, it has the other pidgin's window marked specially (like when I first start it up), but it seems to try to start and then stops, and then when unloading whatsapp crashes the same way, but I haven't debugged that one, I'll probably try to debug with the config you gave me when I'm able to. (I've also noticed that |
It seems to enable additional output, but does not enrich the stack trace. You may leave it in. The
I hope so. I do not have much experience with Arch to be sure.
Pidgin tries to detect other instances to avoid configuration directory corruption. If you want multiple instances, pass the Update: I spent four more hours investigating this issue. Eventually I read the libpurple source (again) and noticed it uses
The more interesting (and uncomfortable) question is: If it is not supported and by design does not work… why did it work so well up to now? It is quite possible that the issue I investigated is not the same as the one reported by you. Update: After thinking about this some more, I came to the conclusion that my aforementioned findings are not relevant to your issue. It is necessary to try a new approach. It looks like with my debug local build, I cannot actually reproduce your exact back-trace. However, I noticed that If you could open up |
|
I've got this: And the crash information from gdb Which I think means that, `bt full` output |
|
Thank you very much for your help in this matter.
I am not sure, either. That option is a boolean. If a true/false value was the source of the problem, then I would be surprised.
This strikes me as odd since the info of purple-gowhatsapp does not even touch the Do not forget to add the braces.
It is looking good. :) |
Do note that I left the other instance up, but that shouldn't change the behaviour, I might later do it again without running the other instance |
|
Without any other instances: |
|
Thank you for the extensive research. In both traces, whatsmeow is looking fine: However, later on, there is another plug-in which actually makes use of dependencies: And releasing those fails. Maybe the log messages were printed slightly out of order. Can you temporarily remove the XMPP Receipts plug-in just to make sure? Not just disable the XMPP Receipts plug-in, but actually remove the .so file from the plugins directory. |
Yes, it seems to be related to that plugin, and as I'm not using XMPP in pidgin, I've uninstalled it, and it no longer happens. I don't think it's required to implement |
Juliaria08
changed the title
|
Thank you for your cooperation and staying on this with me until the end. 🙂 There is also a copy over here. I have no idea which is the more relevant and/or maintained one. The purple documentation says in regard to the dependencies member:
The XMPP Receipts plugin uses a pointer to a struct allocated in static memory. So that definitely is an error in their implementation. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Attached below is a
bt fullfrom pidgin (Pidgin 2.14.13 (libpurple 2.14.13)) crashing after a double free, as told by grim on IRC.I can reproduce this reliably every time I close pidgin, and if guided on how to, (given the exact gdb commands) I can try to get more information by viewing the generated core files or by inspecting a attached process in this state.
I will need to be reminded to set the proper debuginfod variable, but that's easy, as I might remind myself.
The problem is the following: every time I close pidgin via the keyboard shortcut (Ctrl-Q), I get a core file because of a double free, I could disable generating core files but I know that's more evil than good.
The text was updated successfully, but these errors were encountered: