Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11997 closed defect

Provide option to disable video chat entirely

Reported by: hircus Owned by: Maiku
Milestone: Component: Voice and Video
Version: 2.7.0 Keywords:
Cc:

Description

Video chat support is still not 100% reliable, and in my experience (on Fedora x86_64) an incoming video request from a Google Talk user would reliably cause Pidgin to enter a busy loop (unresponsive interface, 100% CPU utilization. Before the recipient (me) is even given the option to accept or reject the call! Thank goodness for multicore CPUs!)

This is a security risk -- it could be used as a Denial of Service tool. There needs to be a dialogue box prompting the user to accept/reject the video request, *before* any of the video subsystem is activated. And there should also be a unified way to disable voice or video functionality across all protocol

Attachments (2)

pidgin-backtrace.log (16.9 KB) - added by hircus 9 years ago.
Backtrace of busy loop at incoming video call
debug-log.txt (52.7 KB) - added by hircus 9 years ago.
Debug log of Pidgin (hircus@…) receiving video invitation from GTalk (michael.silvanus@…)

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by darkrain42

  • Status changed from new to pending

Please follow the instructions to get a debug log and attach it to this ticket.
There is such a prompt -- the fact you're seeing a busy loop is a bug. Please upgrade to 2.7.0 and get a debug log.

comment:2 Changed 9 years ago by hircus

  • Status changed from pending to new

pidgin 2.7.0 has recently entered Fedora's testing repository, so I'll try getting a backtrace. Would have to wait until someone with a Windows or Mac computer...

Changed 9 years ago by hircus

Backtrace of busy loop at incoming video call

comment:3 Changed 9 years ago by hircus

  • Version changed from 2.6.6 to 2.7.0

Just retried this with 2.7.0.

  • The pop-up window for the incoming call notification did appear, but its content is never drawn -- Pidgin stops repainting all its windows at that moment.
  • I used 'sudo debuginfo-install pidgin' and verified that glibc, gtk2, gstreamer, etc. also have their -debuginfo subpackages installed. However, there are still some "values optimized out" in the backtrace. If you could suggest other packages that need to have their debugging information made available, please let me know

comment:4 Changed 9 years ago by darkrain42

  • Status changed from new to pending

Please follow the instructions to get a debug log and attach it to this ticket.
Help->Debug Window (or probably pidgin -d) output, too, please. This looks like it might be a farsight issue, though.

comment:5 Changed 9 years ago by hircus

  • Status changed from pending to new

I did follow the instructions. I can give you the "pidgin -d" output as well, but unfortunately, as you can see from my description of the busy loop, providing the Help->Debug Window output would be nigh impossible as once this bug is triggered, Pidgin does not respond at all.

Will post an updated log in a few hours.

comment:6 Changed 9 years ago by darkrain42

  • Status changed from new to pending

You got a backtrace, which is not the same thing as a 'debug log' (the Debug Window or "pidgin -d" output).

And yes, the Debug Window wouldn't work, which is why I also said "(or probably pidgin -d)" (the two give the same output).

comment:7 Changed 9 years ago by hircus

  • Status changed from pending to new

Just noticed that the debug log instruction is indeed in the Wiki. The problem is that it's in the section for "Windows users", and the section for all other OSes just has a link to the GetABacktrace with nothing said about generating a debug log (even though the debug instructions for Windows can be easily adapted for Unix)

comment:8 Changed 9 years ago by darkrain42

  • Status changed from new to pending

Changed 9 years ago by hircus

Debug log of Pidgin (hircus@…) receiving video invitation from GTalk (michael.silvanus@…)

comment:9 Changed 9 years ago by hircus

  • Status changed from pending to new

Attachment (debug-log.txt) added by ticket reporter.

comment:11 in reply to: ↑ description Changed 9 years ago by malu

Replying to hircus:

Video chat support is still not 100% reliable, and in my experience (on Fedora x86_64) an incoming video request from a Google Talk user would reliably cause Pidgin to enter a busy loop (unresponsive interface, 100% CPU utilization. Before the recipient (me) is even given the option to accept or reject the call! Thank goodness for multicore CPUs!)

This is a security risk -- it could be used as a Denial of Service tool. There needs to be a dialogue box prompting the user to accept/reject the video request, *before* any of the video subsystem is activated. And there should also be a unified way to disable voice or video functionality across all protocol

I think this is a bug in Farsight2 that is fixed in newer versions (the latest is 0.0.19), and I believe a similar issue happens in Empathy. So, you could try upgrading to a newer Farsight2 version and see if the problem is still present.

Thanks for the help.

comment:12 Changed 9 years ago by darkrain42

  • Status changed from new to pending

comment:13 Changed 9 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:14 Changed 9 years ago by hircus

I just updated Farsight to 0.0.20 and it definitely does not crash anymore -- though there is still a problem on the encoding side; the codec chosen on my side is not compatible with Google's Voice/Video? plugin for Gmail.

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!