GNOME Bugzilla – Bug 343345
gdk_pixbuf_scale_simple spins with 100% cpu
Last modified: 2010-07-10 04:05:34 UTC
Please describe the problem: When Rhythmbox is minimised to system tray it will play a few songs and then freeze - it does not respond to mouseclicks or keyboard commands. After an arbitrary delay ~15 minutes it starts playing the next song. Steps to reproduce: 1. Minimise RB to system tray 2. Leave it playing songs (shuffle on) 3. Actual results: Rhythmbox freezes. Then recovers after ~15minutes. Expected results: Normal playback Does this happen every time? Yes, I think so Other information: I ran rhythmbox all day today with -d active. I have had no problems. This suggests to me that there is some sort of race-condition occurring which is eliminated when being debugged. Please let me know if you require more information. I'm running Ubuntu Dapper on an AMD64 system but the same thing happens on a 32bit system.
I'm not seeing this happen at all. Which plugins do you have enabled? Can you get a stack trace from when it's frozen?
Something similat happens here with HEAD, but I haven't waited 15 min to see if starts working. Can you see if it takes 100% CPU when rb freezes ? It does for me.
Victor, what configuration options do you build rb with? This is mine: configure: Rhythmbox was configured with the following options: configure: ** Tree database is enabled configure: Tag writing is disabled configure: ** Track transfer is enabled - USE AT YOUR OWN RISK configure: ** Multimedia keys support is enabled configure: ** MusicBrainz support is enabled configure: ** GStreamer 0.10 player is enabled configure: iPod integration disabled configure: DAAP (music sharing) support is disabled configure: ** libnotify support is enabled configure: ** HAL support enabled configure: ** Python support enabled configure: Audioscrobbler support disabled configure: ** Separate metadata helper process enabled configure: using internal libsexy configure: End options Yes, mine uses 100% cpu as well. Just rebuilt today and can't get it to freeze. Typical... I'll keep you posted on this.
configure: Rhythmbox was configured with the following options: configure: ** Tree database is enabled configure: Tag writing is disabled configure: Track transfer is disabled configure: ** Multimedia keys support is enabled configure: ** MusicBrainz support is enabled configure: ** GStreamer 0.10 player is enabled configure: iPod integration disabled configure: ** DAAP (music sharing) support is enabled configure: ** libnotify support is enabled configure: ** HAL support enabled configure: ** Python support enabled configure: ** Audioscrobbler support enabled configure: ** Separate metadata helper process enabled configure: ** using system-wide libsexy configure: End options I have the following plugins enabled: Last.fm, Lyrics, Artist/Album Browser (not in stock), Art Display. I am disabling them one by one and will see how it goes, but this may take a bit of time .
This one is going to be a difficult one I think... From what I can tell it only seems to happen when I have the art display plugin enabled and rhythmbox minimised. But sometimes it doesn't happen straight away.
When it has frozen, could you run "gdb --pid=`pidof rhythmbox`" in a terminal, and then enter "thread apply all bt" and put the output here?
Just happened again (Using latest head by the way). Here is the debug trace as requested: (gdb) thread apply all bt
+ Trace 68705
Thread 1 (Thread 1115969888 (LWP 4234))
Another trace; this only happens with the art plugin and rb minimised
+ Trace 68780
Thread 1 (Thread -1227602240 (LWP 5434))
This appears to be a GDK bug (I have a trivial C testcase), so I'm reassigning there.
Created attachment 68397 [details] testcase This is a trivial testcase compilable with "gcc `pkg-config --cflags --libs gtk+-2.0 ` -o testcase gdk-pixbuf-scale-1-testcase.c", and then run with "./testcase /path/to/some/image". gdk_pixbuf_scale_simple spins with 100% cpu when width=1, height=1 and interp_type is anything other than GDK_INTERP_NEAREST. A quick profiling indicates that virtually all the time is being spent in pixops_process, but I don't have full debu symbols installed for gtk, so that may be wrong. I haven't completely checked whether it occurs with gdk_pixbuf_scale simple, but I assume it would.
doesn't hang here...
I am also seeing the infinite cpu spin with RB minimised and using the art cover. I tried the testcase with a png ~ 100x100 pixels - it exited cleanly. I also tried with some 2560x1920 pixel jpegs from my camera and I get: GLib-ERROR **: gmem.c:135: failed to allocate 5037753344 bytes aborting... Aborted which is a little disturbing.
I've just tried this with Gtk 2.10, and it's still occurring. When running my test on a square plain white PNG image, the running times are: <=95px negligable 96 0.2 sec 97 0.8 sec 98 3.2 sec 99 6.3 sec 100 8.8 sec 101 9.8 sec 102 0.1 sec 110 0.1 sec 120 27 sec 130 13 sec 134 0.2 sec 140 42 sec 160 111 sec ... In general it goes up largely with the size, however there are certain sizes where it runs very quickly. Those quick times are seemingly random, but consistent - and they're not things that would be an obvious fast-path like powers of two. After about 200px square it's taking over 10 minutes, so I haven't really checked. Why resizing a 200x200 image to 1x1 takes that long I don't know, something funky must be going on. Scaling to a 1x2 or 2x1 image always runs quickly regardless of size, it appears to only be 1x1 that causes this.
Can you attach one of the PNGs that it's slow on?
gdk-pixbuf works really badly for large downscale factors; see bug 80925. The algorithm it uses really falls over in that case, and it will allocate many megabytes of temporary matrices. I suspect that this is just a duplicate of that. I'm not sure why you are getting such big differences between different sizes. Maybe you are running out of memory and into swap.
Yeah, this look to be a dupe of bug 80928. I've just committed a few minor changes to Rhythmbox so that we shouldn't trigger it any more: don't fade between art when minimised, don't ever scale to 1x1 (just hide it) and use known-good values for the widget width. So either this should be marked as a dupe of bug 80928, or moved back to Rhythmbox and closed.
*** This bug has been marked as a duplicate of 80925 ***