Opened 9 years ago

Closed 8 years ago

#12660 closed defect (fixed)

MSN prpl starts file transfers several times (leaks file handles)

Reported by: TeraByte911 Owned by: QuLogic
Milestone: 2.7.6 Component: MSN
Version: 2.7.3 Keywords:
Cc:

Description

File transfers received by Pidgin in Windows can't be opened without restarting Pidgin. Only occurs on the Windows platform (tested on Linux and doesn't occur there). Happens with all IM protocols.

Attachments (1)

locked.png (75.3 KB) - added by TeraByte911 9 years ago.
Example of error message when trying to open received file.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 9 years ago by TeraByte911

  • Component changed from unclassified to winpidgin (gtk)
  • Owner changed from rekkanoryo to datallah

comment:2 Changed 9 years ago by TeraByte911

Confirmed by at least two other users of Pidgin on Windows.

comment:3 Changed 9 years ago by datallah

  • Status changed from new to pending

What exactly do you mean by "can't be opened"? What kinds of files are you transferring? Can you provide some steps that can be followed specifically to reproduce the problem you are having?

Changed 9 years ago by TeraByte911

Example of error message when trying to open received file.

comment:4 Changed 9 years ago by TeraByte911

  • Status changed from pending to new

Attachment (locked.png) added by ticket reporter.

comment:6 Changed 9 years ago by TeraByte911

  • What exactly do you mean by "can't be opened"?

Please see the attached screenshot of the error I am referring to.

  • What kinds of files are you transferring?

Anything. The error isn't limited to one file type.

  • Can you provide some steps that can be followed specifically to reproduce the problem you are having?

Simply receive a file from a contact (such as an image file) and try to open it without closing Pidgin.

comment:7 Changed 9 years ago by Dimmuxx

Which protocol are you using?

comment:8 Changed 9 years ago by TeraByte911

I've noticed the behaviour on several protocols, but the main ones would have to be Google Talk and MSN.

comment:9 Changed 9 years ago by datallah

  • Component changed from winpidgin (gtk) to MSN
  • Owner changed from datallah to QuLogic
  • Summary changed from File transfers in Windows can't be opened to MSN prpl starts file transfers several times (leaks file handles)

I suspect that you're really only seeing this with MSN.

It doesn't appear that the bug I've tracked this down to could occur with XMPP.

comment:10 Changed 9 years ago by datallah@…

(In 2fa8397877be345efa9c19c1530ad7686236d8e4):
Beginning a file transfer multiple times leaks file handles. Add some debugging and guarding to detect and avoid that.

This is only part of the full fix (mostly to help bring attention to the problem)

The real problem is that in the MSN prpl (and possibly others), file transfers are started multiple times. This happens for every file transfer over MSN that I've tested.

Refs #12660

comment:11 Changed 9 years ago by datallah

Here is the backtrace from the first start:

Breakpoint 2, begin_transfer (xfer=0x1953a20, cond=PURPLE_INPUT_READ) at ft.c:1290
1290	{
(gdb) bt full
#0  begin_transfer (xfer=0x1953a20, cond=PURPLE_INPUT_READ) at ft.c:1290
        type = <value optimized out>
        ui_ops = <value optimized out>
#1  0x00007facd684d442 in msn_slplink_process_msg (slplink=0x21200e0, header=0x23b2160, 
    data=0x23764b4 "\342\004", len=0) at slplink.c:606
        slpmsg = 0x2110ee0
        offset = 0
        xfer = 0xffffffff
        __PRETTY_FUNCTION__ = "msn_slplink_process_msg"
#2  0x00007facd6835b78 in msn_dc_process_packet (data=0x23b2090, fd=<value optimized out>, 
    cond=<value optimized out>) at directconn.c:653
No locals.
#3  msn_dc_recv_cb (data=0x23b2090, fd=<value optimized out>, cond=<value optimized out>) at directconn.c:733
        bytes_received = <value optimized out>
        packet_length = 48
        __PRETTY_FUNCTION__ = "msn_dc_recv_cb"
#4  0x000000000046de4e in pidgin_io_invoke (source=<value optimized out>, condition=<value optimized out>, 
    data=<value optimized out>) at gtkeventloop.c:73
        closure = 0x23c8720
        purple_cond = PURPLE_INPUT_READ
#5  0x00007face0dfc8c2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0

and the second start:

Breakpoint 2, begin_transfer (xfer=0x1953a20, cond=PURPLE_INPUT_READ) at ft.c:1290
1290	{
(gdb) bt
#0  begin_transfer (xfer=0x1953a20, cond=PURPLE_INPUT_READ) at ft.c:1290
#1  0x00007facd684d442 in msn_slplink_process_msg (slplink=0x21200e0, header=0x23b2160, 
    data=0x23764b4 ..., len=1202) at slplink.c:606
#2  0x00007facd6835b78 in msn_dc_process_packet (data=0x23b2090, fd=<value optimized out>, 
    cond=<value optimized out>) at directconn.c:653
#3  msn_dc_recv_cb (data=0x23b2090, fd=<value optimized out>, cond=<value optimized out>) at directconn.c:733
#4  0x000000000046de4e in pidgin_io_invoke (source=<value optimized out>, condition=<value optimized out>, 

It is easy enough to recreate by adding a breakpoint on begin_transfer and then receiving a file.

comment:12 Changed 9 years ago by datallah

Ticket #12769 has been marked as a duplicate of this ticket.

comment:13 Changed 8 years ago by qulogic@…

  • Milestone set to 2.7.6
  • Resolution set to fixed
  • Status changed from new to closed

(In dae066f644c6889a92dbe25067e635747c28a900):
Don't attempt to process zero-length DC messages. We should probably just use these for acking or something.

Fixes #12660.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!