Bug 919288

Summary: Finch and PIdgin are both unresponsive in Rawhide
Product: [Fedora] Fedora Reporter: Michel Lind <michel>
Component: pidginAssignee: Stu Tomlinson <stu>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: itamar, jsynacek, stu
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-14 06:44:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Backtrace after CTRL-C on non-responding Pidgin none

Description Michel Lind 2013-03-08 01:54:23 UTC 
Description of problem:
Pidgin works fine in F18, however, after upgrading my machine to Rawhide, the interface becomes unresponsive soon after launching. The first time I tried it, the buddy list window was still unpopulated when that happens; the second time, it displayed some information, but became unresponsive while still connecting.

In case it's a GTK problem, I tried installing Finch, and the same occurs - it doesn't respond to the documented shortcuts after displaying the menu prompting to select which IM accounts to use.

Version-Release number of selected component (if applicable):
libpurple-2.10.7-2.fc19.x86_64
finch-2.10.7-2.fc19.x86_64
pidgin-2.10.7-2.fc19.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Upgrade to Rawhide
2. Install pidgin or finch
3. Launch either
  
Actual results:
Interface unresponsive before app can be used

Expected results:


Additional info:
Comment 1 Michel Lind 2013-03-08 03:26:25 UTC 
Could be related to the linked Ubuntu bug
Comment 2 Michel Lind 2013-03-08 03:27:21 UTC 
Created attachment 706902 [details]
Backtrace after CTRL-C on non-responding Pidgin
Comment 3 Michel Lind 2013-03-08 03:30:32 UTC 
Debug log when connecting to a Yahoo account (last line appears after several seconds, after the GUI is already unresponsive)

(10:22:38) account: Connecting to account hircus.
(10:22:38) connection: Connecting. gc = 0x241b940
(10:22:38) util: Writing file /home/michel/.purple/icons/52fb4aba347b28923ae18b7254161152f04cfe29.png
(10:22:38) yahoo: Calculated buddy icon checksum: 892744962
(10:22:38) yahoo: buddy icon is up to date. Not reuploading.
(10:22:38) util: requesting to fetch a URL
(10:22:38) dnsquery: Performing DNS lookup for vcs1.msg.yahoo.com
(10:22:38) dns: Created new DNS child 6705, there are now 1 children.
(10:22:38) dns: Successfully sent DNS request to child 6705
(10:22:39) dns: Got response for 'vcs1.msg.yahoo.com'
(10:22:39) dnsquery: IP resolved for vcs1.msg.yahoo.com
(10:22:39) proxy: Attempting connection to 66.196.120.43
(10:22:39) proxy: Connecting to vcs1.msg.yahoo.com:80 with no proxy
(10:22:39) proxy: Connection in progress
(10:22:39) proxy: Connecting to vcs1.msg.yahoo.com:80.
(10:22:39) proxy: Connected to vcs1.msg.yahoo.com:80.
dns[6705]: nobody needs me... =(
Comment 4 Michel Lind 2013-03-14 06:13:50 UTC 
And today Pidgin suddenly works, without any modification; same versions as above. The only change I did is reverting systemd 197's renaming of network devices. Will post an update after I check whether re-enabling that feature breaks Pidgin again or not.
Comment 5 Michel Lind 2013-03-14 06:44:42 UTC 
With or without systemd 197's renaming of network device, the bug now cannot be consistently reproduced - I got one lock up just now with the old-style device name, which went away after I force-killed pidgin and restarted it, but no lock up the previous time I tried in this configuration, and no lock up with the new-style device name.

Closing for now, will reopen if this reoccurs and I have more details as to what's causing it.