- Change Summary:
-
Built on windows and verified it worked there.
- Commits:
-
Summary ID da19e5e36d99793ccec3ae20ac0902d251ae1447 6268005acd9fc2cd9bf520ce77f063887890b447 - Diff:
-
Revision 2 (+864 -558)
Convert the bonjour protocol plugin to the new status api and contacts
Review Request #2427 — Created April 7, 2023 and submitted
This has been tested on linux and windows. Apparently we don't build for mac right now. I didn't test file transfers at all though.
Created and account and sent some messages to my Pidgin2 account.
Summary | ID |
---|---|
e212b1476be720af6c20d367916c7422568790e5 |
Description | From | Last Updated |
---|---|---|
When testing file transfer I got a SIGSEGV which I do not get without these changes. Here's the backtrace: #0 … |
ivanhoe | |
I'm getting a seemingly infinite loop when closing Pidgin3 with lots of g_object_get_data: assertion 'G_IS_OBJECT (object)' failed Steps to reproduce: … |
ivanhoe | |
My understanding is that g_object_get_data(G_OBJECT(contact), "bonjour-buddy"); will return a BonjourBuddy not a BonjourData so bd seems to be the wrong … |
ivanhoe | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
I think this person leaks since purple_contact_info_set_person is transfer none. |
QuLogic | |
'pointer is valid' |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Leaks |
QuLogic | |
Probably leaks, but I did not confirm all callers of _find_or_start_conversation. |
QuLogic | |
contact is passed to an async call here; should we ref it and unref in the callback? |
QuLogic | |
This doesn't change in the loop, I think, so can probably be lifted out? |
QuLogic | |
Sorry, missed that the last arg is a GDestroyNotify, so that should be passed instead of an unref in the … |
QuLogic | |
Should we add an ref here as well? |
QuLogic | |
Ditto. |
QuLogic | |
Missing contact unref here. |
QuLogic |
- Description:
-
~ This has not yet been tested on mac and will require updates for it. I'll be getting to that in the next few days.
~ This has been tested on linux and windows. Apparently we don't build for mac right now. I didn't test file transfers at all though.
- - However, that should all be in
mdns_dns_sd.[ch]
so the current should be able to be reviewed whenever.
- Change Summary:
-
rebased
- Commits:
-
Summary ID 6268005acd9fc2cd9bf520ce77f063887890b447 53062ff9b7fffd821367cc121a02b8cf09d5afac - Diff:
-
Revision 3 (+864 -558)
- Bugs:
- Change Summary:
-
rebased and addressed the issue.
- Commits:
-
Summary ID 53062ff9b7fffd821367cc121a02b8cf09d5afac 460c9ab05526c9cfa861dad50f5d4969c818205f - Diff:
-
Revision 4 (+862 -556)
-
-
When testing file transfer I got a SIGSEGV which I do not get without these changes. Here's the backtrace:
#0 0x00007ffff7a4c783 in g_type_check_instance_cast () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #1 0x00007ffff0448aea in XEP_XFER (ptr=0x5555555b51d0) at ../libpurple/protocols/bonjour/bonjour_ft.h:30 #2 0x00007ffff0449078 in bonjour_si_xfer_find (bd=0x555556d04970, sid=0x555557279b20 "2", from=0x555556c5aea0 "driftwood@driftwood") at ../libpurple/protocols/bonjour/bonjour_ft.c:167 #3 0x00007ffff044a7f2 in xep_bytestreams_parse (pc=0x555555649d20, packet=0x5555573e4ba0, contact=0x555556c08a60) at ../libpurple/protocols/bonjour/bonjour_ft.c:706 #4 0x00007ffff044774a in xep_iq_parse (packet=0x5555573e4ba0, contact=0x555556c08a60) at ../libpurple/protocols/bonjour/xmpp.c:1359 #5 0x00007ffff0444b04 in bonjour_xmpp_process_packet (contact=0x555556c08a60, packet=0x5555573e4ba0) at ../libpurple/protocols/bonjour/xmpp.c:382 #6 0x00007ffff04487cf in bonjour_parser_element_end_libxml (user_data=0x555556bfe760, element_name=0x55555711c8b9 "iq", prefix=0x0, namespace=0x55555711c82e "jabber:client") at ../libpurple/protocols/bonjour/parser.c:142 #7 0x00007ffff67ccf25 in () at /lib/x86_64-linux-gnu/libxml2.so.2 #8 0x00007ffff67da459 in () at /lib/x86_64-linux-gnu/libxml2.so.2 #9 0x00007ffff67db70b in xmlParseChunk () at /lib/x86_64-linux-gnu/libxml2.so.2 #10 0x00007ffff0448999 in bonjour_parser_process (bconv=0x555556bfe760, buf=0x7ffff045dc00 <message> "<iq to='maat@maat' from='driftwood@driftwood' id='2' type='set'><query xmlns='http://jabber.org/protocol/bytestreams' sid='2' mode='tcp'><streamhost jid='2' host='fe80::8b35:34c6:6140:6e4b' port='3322"..., len=390) at ../libpurple/protocols/bonjour/parser.c:232 #11 0x00007ffff0444e3c in _client_socket_handler (stream=0x55555705b670, data=0x555556bfe760) at ../libpurple/protocols/bonjour/xmpp.c:459 #12 0x00007ffff7e1267f in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
- Change Summary:
-
Fix the new crash which was another case of accidentally setting a bonjour data to a bonjour buddy.
- Commits:
-
Summary ID 460c9ab05526c9cfa861dad50f5d4969c818205f 76bb29442b8f9d624c011262d544a34b0a1c9761 - Diff:
-
Revision 5 (+860 -554)
-
-
I'm getting a seemingly infinite loop when closing Pidgin3 with lots of
g_object_get_data: assertion 'G_IS_OBJECT (object)' failed
Steps to reproduce: * in Pidgin3 open a conversation with a Bonjour contact * Conversation -> Send File... * Choose a file and send it * Accept the file on the other end (in my case with Pidgin2) * Pidgin3 reports File transfer failed (which it does also without the changes of this RR) * Close all dialogs and the Pidgin3
- Change Summary:
-
address leaks
- Commits:
-
Summary ID 76bb29442b8f9d624c011262d544a34b0a1c9761 f7b3f60ca980f407dc4e4f9de50f22564456bd23 - Diff:
-
Revision 6 (+934 -554)
- Change Summary:
-
fix the infinite loop, can't believe this one snuck though, actually maybe I can, that for loop was noisy af!
- Commits:
-
Summary ID f7b3f60ca980f407dc4e4f9de50f22564456bd23 e65d23b43da7444636ed96cd7392c29f94703b56 - Diff:
-
Revision 7 (+934 -554)
- Change Summary:
-
address issues
- Commits:
-
Summary ID e65d23b43da7444636ed96cd7392c29f94703b56 6bc421f686a4760fee83357c072790eb5cc66e61 - Diff:
-
Revision 8 (+966 -562)
- Change Summary:
-
address issues
- Commits:
-
Summary ID 6bc421f686a4760fee83357c072790eb5cc66e61 e212b1476be720af6c20d367916c7422568790e5 - Diff:
-
Revision 9 (+960 -562)