gnomad2 uses 100% cpu

[chrisV]

Binary package hint: gnomad2

On Intrepid, gnomad2 uses 100% cpu after it has been started on my x86 machine - not viciously so, as it is not a tight loop, but is a callback loop in GMainLoop. However, it can easily be observed by starting gnomad2 and then running top, and is prejudicial to my laptop battery life.

This is caused by calling g_idle_add() in src/filelist.c and src/jukebox.c being passed a callback (gtk_widget_destroy()) with a void return type, rather than a callback with gboolean return type which returns FALSE.

A patch which deals with this is attached.

[Brian Murray (brian-murray)]

I was unable to recreate this on Jaunty Jackalope using gnomad2 version 2.9.1-1.1ubuntu1 on an amd64 machine. Do you happen to have an mtp device connected when you find this bug? Thanks in advance.

[chrisV (chris-cvine)]

Yes I do. I get the problem with and without a MTP device connected.

If you look at the patch though, you will see that there is a clear error in the original code. Whether the bug actually strikes is probably hardware/processor/compiler dependent. It depends on what return value the compiler will happen to "see" from the callback when the callback is in fact of void type.

Chris

[chrisV (chris-cvine)]

By the way, if you have multiple cores you may need to use mpstat to see it, and you may not see it at all with mpstat if the scheduler shifts the main loop iterations to different cores (but the busy iterations will still be happening).

Chris

[chrisV (chris-cvine)]

In case I have been assuming too much background knowledge, the point about main loop callbacks inserted with g_idle_add() is that they will keep being called on main loop iterations until the callback returns 0 (FALSE). With a callback with void type that will be random - no doubt with some machines/architectures it will happen eventually, on some (possibly yours) perhaps always, but with my hardware it doesn't happen at all. Happily the repeated calls to gtk_widget_destroy won't do anything too awful (apart from occupying CPU time) because GTK+ will detect that a widget is no longer at that address.

Chris

[Brian Murray (brian-murray)]

We won't be able to get this fix in for Jaunty so it would be great if you could forward the bug and the patch upstream so we can pull the fix in for Karmic. Thanks in advance.

[chrisV (chris-cvine)]

I posted a bug upstream on the sourceforge gnomad2 tracker when I made the launchpad bug report for Intrepid ( http://sourceforge.net/tracker/?func=detail&aid=2758754&group_id=65573&atid=511470 ).

However the project looks a bit moribund - the project webpage still gives the last release as 2.9.1 whereas the sourceforge FRS goes up to 2.9.4. Shame, because I have found it to be the best of the programs (for gnome at least) for using my MTP stick. You may therefore have to apply the patch to the ubuntu package yourselves. Anyway, let's see what transpires.

Chris

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnomad2 - 2.9.4-0ubuntu1

---------------
gnomad2 (2.9.4-0ubuntu1) karmic; urgency=low

  * New upstream release (LP: #358944)
  * debian/control: Add build-depends on intltool (>= 0.35.0).
  * debian/watch: Update to handle Sourceforge location.
  * Drop patch in src/jukebox.c, src/tagfile.c, and gnomad2.desktop.in.
    There are merged upstream.
  * Include inline patch in src/filesystem.c and src/jukebox.c to fix a 100%
    CPU use. Thanks Chris Vine for the patch (LP: #360442)

 -- Julien Lavergne <email address hidden> Tue, 14 Jul 2009 14:34:33 +0200