This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 217763 - Can lock up gnome while resizing chat box with an image in it in gaim
Can lock up gnome while resizing chat box with an image in it in gaim
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: pidgin (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Warren Togami
David Lawrence
bzcl34nup
: Desktop, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-29 15:08 EST by Ben Levenson
Modified: 2008-05-06 21:01 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:01:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Backtrace of gaim showing gtk2 issue. (20.77 KB, text/plain)
2006-11-30 16:30 EST, Tim Reilly
no flags Details

  None (edit)
Description Tim Reilly 2006-11-29 15:08:10 EST
Description of problem:
1. Insert an image inline (normally would have to direct connect but we'll crash
this before then)
2. Resize text entry box so that gaim has to scale the image up and down in size
3. GNOME locks up

It doesn't always crash right away, but I can reproduce this 100% on both my
fedora (gaim 2 beta5) and rhel5 (gaim 2 beta 4) machines. From the GNOME-wide
aspect of the crash, it seems like it might not be just gaim, but this can be a
start.
Comment 1 Warren Togami 2006-11-29 16:15:42 EST
Could you please install all relevant debuginfo and run gaim in gdb until you
get a good traceback?

http://gaim.sourceforge.net/gdb.php
Follow these directions and attach the result here.

You could also test if your issue is related to Bug #216034, which is soon fixed
in both RHEL5 and FC6.
Comment 2 Tim Reilly 2006-11-29 16:56:30 EST
As far as I can tell, this isn't a similar bug to #216034, I don't have several
gnome_segv or bug-buddy entries in ps during the hang. 

The debuginfo package for gaim was for beta3 instead of beta5 on the repo I'm
using... it said crc mismatch a lot of times, is that OK? Also, what debuginfo
packages beyond gaim's do I need?
Comment 4 Lawrence Lim 2006-11-29 19:24:32 EST
Crashing bug. Propose as BLOCKER to continue investigation.
Comment 7 Ray Strode [halfline] 2006-11-30 15:57:06 EST
what do you mean by locks up?  If you change your clock applet to show seconds,
do the seconds still update?  Can you still ping the machine?  if you ssh in and
kill gaim does your session recover?
Comment 9 Tim Reilly 2006-11-30 16:30:02 EST
Created attachment 142530 [details]
Backtrace of gaim showing gtk2 issue.
Comment 10 Tim Reilly 2006-11-30 16:33:52 EST
Sorry, got a little held up. The desktop is completely unusable, but the clock
updates. Killing gaim by ctrl+alt+f1 terminals brings gnome back. I tried
toggling the composite extension in X a bunch of times but it didn't reveal a
difference in behavior.

The backtrace seems to pretty clearly indicate that gtk2 is part of the problem,
though IANAP.
Comment 11 Warren Togami 2006-11-30 19:25:33 EST
Reassigning to gtk2 because this is likely triggerable by more than just gaim. 

Please note that this is a RHEL5 blocker.
Comment 12 Matthias Clasen 2006-11-30 21:05:22 EST
Comment 10 sounds more like a stuck grab in gaim to me.
Comment 13 Matthias Clasen 2006-12-01 14:59:44 EST
Also, I don't have any sort of account that would allow me to insrt images inline...

While the stack trace does not quite show it, my assumption is that the
following is happening:

1) gtk holds a grab during the resizing of the pane
2) gaim blindly rescales the image whenever the pane changes
3) your resizing makes the pane very small
4) scaling down an image a lot with gdk-pixbuf sucks a lot, which is well known

Comment 14 Warren Togami 2006-12-01 15:17:06 EST
mclasen, apparenetly it can be done with a simple AIM account.

Hmm... I'm unable to reproduce this myself with a JPG and PNG image.

treilly, could you please attach the image that you used to trigger this?
Comment 15 Tim Reilly 2006-12-01 17:11:03 EST
Created attachment 142629 [details]
One image used to crash gaim

I've crashed gaim with other images but this is the one I've been using most of
the time so far.
Comment 16 Warren Togami 2006-12-11 16:01:28 EST
treilly, would you agree that this is extremely difficult to trigger and rare,
thus we shouldn't block RHEL5 for this issue?
Comment 17 Tim Burke 2006-12-11 16:11:53 EST
I tried this myself on an x86 install. Inserted image and resized.  Worked fine.
Then resized like 10 more times, finally it hung the gaim application. The rest
of my system is fine, including other windows. Just the gaim application became
unresponsive, and not repainting the screen when dragged around. I notice while
it is hung that when looking in `ps`, that the gaim application continues to run
up cpu time:

[root@burkelaptop ~]# ps ax | grep gaim
 4983 ?        R      1:35 gaim
 5013 pts/0    R+     0:00 grep gaim
[root@burkelaptop ~]# ps ax | grep gaim
 4983 ?        R      1:37 gaim
 5015 pts/0    S+     0:00 grep gaim
Comment 18 Tim Reilly 2006-12-11 16:31:16 EST
I'd agree that is rare and probably not a high priority blocker, even if it is a
crasher. I found it just under general use (not explicitly trying to break gaim).

I experience different symptoms from tburke, all of gnome is unresponsive unless
I kill gaim, though both my machines are i386
Comment 19 Tim Burke 2006-12-11 16:33:58 EST
While I didn't find this extremely difficult to trigger... I don't consider
inserting an image and rapidly, repeatedly resizing the gaim window to be a
frequently performed operation.  Sure, this would be nice to fix, but I wouldn't
consider it a true release blocker severity.
Comment 20 Tim Reilly 2006-12-11 16:42:13 EST
I've had it trigger on a single resize a couple times now. It takes somewhere
between 1 and maybe 10 resizes to lock up.
Comment 22 RHEL Product and Program Management 2007-03-21 19:34:09 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 24 Daniel Riek 2007-06-11 11:08:57 EDT
GAIM / PIDGIN is going to be released asynchronously, but these issues are not
going to be addressed. Closing DEFERRED.

If they are important, they can be re-opened for a future minor release.
Comment 25 Warren Togami 2007-06-11 14:35:25 EDT
Please don't close these bugs as DEFERRED.  CLOSED DEFERRED will make it
disappear from the radar forever.
Comment 26 RHEL Product and Program Management 2007-06-11 14:45:25 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 28 Daniel Riek 2007-10-04 15:26:21 EDT
Moved to 5.2 so resetting old acks.
Comment 31 Bug Zapper 2008-04-03 14:43:50 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 32 Bug Zapper 2008-05-06 21:01:33 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.