After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580022 - Accessing shell.props.queue_source in python plugins makes RB crash
Accessing shell.props.queue_source in python plugins makes RB crash
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: Plugins (other)
0.12.x
Other All
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 594197 594276 608654 608893 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-23 20:56 UTC by Oben Sonne
Modified: 2011-07-25 18:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Oben Sonne 2009-04-23 20:56:19 UTC
Steps to reproduce:
1. Open the Python console

2. Try to access the queue source:
>>> qs = shell.props.queue_source

3. Rhythmbox crashes:
--- snip ---
:~$ rhythmbox
**
ERROR:/build/buildd-pygobject_2.16.1/gobject/pygobject.c:925:pygobject_new_full: assertion failed: (tp != NULL)
Aborted
--- end: snip ---

Stack trace:
$ gdb rhythmbox
GNU gdb 6.8-debian
...
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /usr/bin/rhythmbox 
[Thread debugging using libthread_db enabled]
[New Thread 0xb61da770 (LWP 6613)]
[New Thread 0xb5e6ab90 (LWP 6617)]
[Thread 0xb5e6ab90 (LWP 6617) exited]
[New Thread 0xb5e6ab90 (LWP 6618)]
[New Thread 0xb4e15b90 (LWP 6619)]
[Thread 0xb4e15b90 (LWP 6619) exited]
[Thread 0xb5e6ab90 (LWP 6618) exited]
[New Thread 0xb5e6ab90 (LWP 6620)]
[New Thread 0xb4e15b90 (LWP 6621)]
[Thread 0xb5e6ab90 (LWP 6620) exited]
[New Thread 0xb5e6ab90 (LWP 6622)]
[Thread 0xb5e6ab90 (LWP 6622) exited]
**
ERROR:/build/buildd/pygobject-2.16.1/gobject/pygobject.c:925:pygobject_new_full: assertion failed: (tp != NULL)

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb61da770 (LWP 6613)]
0xb7efb422 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 1 (Thread 0xb61da770 (LWP 6613))

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libc.so.6
  • #2 abort
    from /lib/tls/i686/cmov/libc.so.6
  • #3 IA__g_assertion_message
  • #4 IA__g_assertion_message_expr
  • #5 pygobject_new_full
    at /build/buildd/pygobject-2.16.1/gobject/pygobject.c line 925
  • #6 pygobject_new
    at /build/buildd/pygobject-2.16.1/gobject/pygobject.c line 950
  • #7 pyg_value_as_pyobject
    at /build/buildd/pygobject-2.16.1/gobject/pygtype.c line 1037
  • #8 pyg_param_gvalue_as_pyobject
    at /build/buildd/pygobject-2.16.1/gobject/pygtype.c line 1609
  • #9 PyGProps_getattro
    at /build/buildd/pygobject-2.16.1/gobject/pygobject.c line 298
  • #10 PyObject_GetAttr
    at ../Objects/object.c line 1197
  • #11 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2059
  • #12 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2968
  • #13 PyEval_EvalCode
    at ../Python/ceval.c line 522
  • #14 PyRun_StringFlags
    at ../Python/pythonrun.c line 1335
  • #15 builtin_eval
    at ../Python/bltinmodule.c line 682
  • #16 PyCFunction_Call
    at ../Objects/methodobject.c line 81
  • #17 PyEval_EvalFrameEx
    at ../Python/ceval.c line 3706
  • #18 PyEval_EvalCodeEx
  • #19 PyEval_EvalFrameEx
    at ../Python/ceval.c line 3802
  • #20 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2968
  • #21 function_call
    at ../Objects/funcobject.c line 524
  • #22 PyObject_Call
    at ../Objects/abstract.c line 2492
  • #23 instancemethod_call
    at ../Objects/classobject.c line 2579
  • #24 PyObject_Call
    at ../Objects/abstract.c line 2492
  • #25 PyEval_CallObjectWithKeywords
    at ../Python/ceval.c line 3575
  • #26 PyObject_CallObject
    at ../Objects/abstract.c line 2480
  • #27 pyg_closure_marshal
    at /build/buildd/pygobject-2.16.1/gobject/pygtype.c line 1110
  • #28 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #29 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3247
  • #30 IA__g_signal_emit_valist
  • #31 IA__g_signal_emit
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3037
  • #32 gtk_widget_event_internal
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkwidget.c line 4761
  • #33 IA__gtk_window_propagate_key_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkwindow.c line 5142
  • #34 gtk_window_key_press_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkwindow.c line 5172
  • #35 _gtk_marshal_BOOLEAN__BOXED
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmarshalers.c line 84
  • #36 g_type_class_meta_marshal
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 878
  • #37 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #38 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3285
  • #39 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 2990
  • #40 IA__g_signal_emit
  • #41 gtk_widget_event_internal
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkwidget.c line 4761
  • #42 IA__gtk_propagate_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 2370
  • #43 IA__gtk_main_do_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 1601
  • #44 gdk_event_dispatch
    at /build/buildd/gtk+2.0-2.16.1/gdk/x11/gdkevents-x11.c line 2364
  • #45 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 1814
  • #46 g_main_context_iterate
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2448
  • #47 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2656
  • #48 IA__gtk_main
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 1205
  • #49 main
    at main.c line 336

Other information:
Originally I've seen this bug caused by a Python plugin where a little more output has been provided just before the assertion error output:

--- snip ---
TypeError: Cannot create a consistent method resolution
order (MRO) for bases Buildable, ImplementorIface, gtk.Orientable
--- end: snip ---

This happened on Ubuntu Jaunty but also has been seen on Debian testing.

I've seen this bug the first time in Jaunty beta on April 16. After installing latest Jaunty updates on the next day the bug disappeared. However, today I installed again the latest updates and now I've seen this bug again.

Please let me know if you need some more information.
Comment 1 Oben Sonne 2009-04-23 21:11:15 UTC
The same crash happens when doing the following in the Python console:
>>> shell.get_player().props.source

If you need the stack trace for this crash too, please let me know it.
Comment 2 Jonathan Matthew 2009-04-24 00:13:37 UTC
Neither of those cause crashes here (debian unstable).  There's virtually no rhythmbox code involved in retrieving properties like that, so I'm pretty sure the problem is elsewhere.
Comment 3 Oben Sonne 2009-04-24 11:50:18 UTC
After searching for this bug elsewhere it seems to be related to pygtk or pygobject. I now managed to create two versions of Jaunty in a virtual machine with different package update states. In one case (most recent updates) the bug occurs and in the other case things work as usual. I'll try to figure out what's the relevant difference there.

Once I have some more information, I'll post it here.
Comment 4 Oben Sonne 2009-05-03 18:24:08 UTC
After upgrading both Jaunty VM installations to the most recent state the bug still occured in one VM while not in the other. So it does not relate to a specific version of a specific package.

Anyway, I do not experience this bug on my main installation. Also I still have no clue how to reproduce this bug.

Since you say the error is probably not related to RB it should be ok to close this bug.
Comment 5 Johannes Rohr 2009-09-05 22:43:32 UTC
*** Bug 594197 has been marked as a duplicate of this bug. ***
Comment 6 Johannes Rohr 2009-09-05 22:45:50 UTC
i just marked bug 594197 as a duplicate of this. It contains a stacktrace. However, I apparantly do not have permission to reopen this bug here.
Comment 7 Oben Sonne 2009-09-05 23:28:29 UTC
Reopen the bug due to last comment by Johannes.
Comment 8 Oben Sonne 2009-09-05 23:32:50 UTC
Johannes, I guess you used the plugin Remuco while the crash occured. Could you please check if you get the same crash when you run

>>> shell.get_player().props.source

in the Rhythmbox Python console? I'm quite sure this is the call of the Remuco plugin which makes RB crash - would be nice if you could verify this.
Comment 9 Johannes Rohr 2009-09-05 23:44:02 UTC
*** Bug 594276 has been marked as a duplicate of this bug. ***
Comment 10 Johannes Rohr 2009-09-05 23:45:16 UTC
(In reply to comment #8)
> Johannes, I guess you used the plugin Remuco while the crash occured. Could you
> please check if you get the same crash when you run
> 
> >>> shell.get_player().props.source
> 
> in the Rhythmbox Python console? I'm quite sure this is the call of the Remuco
> plugin which makes RB crash - would be nice if you could verify this.

Just tried, the result is in bug 594276 which is marked a duplicate of this one.
Comment 11 spe.stani.be 2009-10-05 20:53:22 UTC
I can confirm that:
>>> shell.get_player().props.source

crashes rhythmbox. I am unable to use the remuco plugin now.
Comment 12 Oben Sonne 2009-10-05 21:24:52 UTC
@Jonathan Matthew:
In comment 2 you said this bug is not related to Rhythmbox.  I'm happy to report this bug elsewhere, but I've no clue about the real problem source. Where would you guess this bug's origin? PyGObject?
Comment 13 Jonathan Matthew 2009-10-05 22:42:05 UTC
pygobject or pygtk.  It may be related to bug 555384.
Comment 14 Jonathan Matthew 2009-12-12 09:36:53 UTC
I can't reproduce this any more. I can't see any changes in pygobject or pygtk that look like they could have fixed it, though.
Comment 15 Jonathan Matthew 2009-12-12 09:47:34 UTC
Very strange.. the code given in bug 538401, which triggers either the same problem or a closely related one, crashes when run in ipython, but runs successfully in the rhythmbox python console, using the same python build.
Comment 16 Johannes Rohr 2009-12-13 11:47:26 UTC
My rhythmbox still reproducibly crashes on this one.
Comment 17 Philip Haynes 2009-12-15 13:31:40 UTC
Some additional information that might help. First, this problem is currently reproducible for me with the python console and from the remuco plugin (my first source of the problem).

system: Linux odin 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 21:27:25 UTC 2009 x86_64 GNU/Linux

just updated my Jaunty installation so all is current as at Wed Dec 16 00:27:19 EST 2009

when I run the command;

>>>shell.props.queue_source

in the python console on my local X Display (ie the display attached to the machine), the instance of rhythmbox crashes as described by others here.

However, if I run an instance of rhythmbox on a remote display, for example from the command line via a ssh -Y the command returns;

<__main__.RBPlayQueueSource object at 0x2ddf140 (RBPlayQueueSource at 0x24c0040)>

my X server in this case is running on a machine;

Darwin Vidar.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

X is XQuartz 2.1.6 (xorg-server 1.4.2-apple33)
Comment 18 Jonathan Matthew 2010-02-01 09:50:36 UTC
*** Bug 608654 has been marked as a duplicate of this bug. ***
Comment 19 Jonathan Matthew 2010-02-03 20:14:09 UTC
*** Bug 608893 has been marked as a duplicate of this bug. ***
Comment 20 Oben Sonne 2010-02-21 12:58:36 UTC
Some news on this. After a user reported this issue when using the Remuco plugin in Ubuntu Studio 9.10 I tried again to reproduce this in virtual machines using VirtualBox.

Indeed I could reproduce this bug in "Ubuntu Studio 9.10" using this ISO image: http://cdimage.ubuntu.com/ubuntustudio/releases/9.10/release/ubuntustudio-9.10-alternate-i386.iso. I did the test right after a fresh installation as well as after getting all updates (as of 17 Feb 2010).

OTH, the same test did not reproduce the bug in a regular "Ubuntu 9.10" (http://cdimage.ubuntu.com/releases/9.10/release/ubuntu-9.10-dvd-i386.iso), so here everything works fine.
Comment 21 quenbert 2010-02-24 18:21:17 UTC
This bug is for sure pygobject related: on my ubuntu 9.10, upgrading from python-gobject 2.10.0-0ubuntu2 to latest stable pygobject 2.20.0 (from sources) solves the problem.
Comment 22 quenbert 2010-02-24 18:22:42 UTC
Should read "...from python-gobject 2.18.0-0ubuntu2 to latest stable..." in my comment above, sorry for the typo
Comment 23 Oben Sonne 2010-02-25 19:36:58 UTC
Hm, I was not able to fix it that way. In both VMs mentioned in comment 20, pygobject 2.18 is installed and this version works in the Ubuntu 9.10 VM but fails in the Ubuntu _Studio_ 9.10 VM. In Studio I installed python-gobject 2.20 from source and in my case it did not fix the problem.
Comment 24 Oben Sonne 2010-03-03 17:35:13 UTC
Just posted a new bug in PyGObject: bug 611721.
Comment 25 pvradu 2010-03-07 13:48:23 UTC
Hi,
i just tried using remuco today. I'm using Ubuntu Karmic 9.10. Thing is, i can't enable Remuco plugin from rhythmbox plugin window, although remuco-rhythmbox is already installed. And the commands in python consule make rhythmbox crash instantly. Well, running rhythmbox as root solves all problems, ...i can enable remuco (and actually works), i can run those commands in python console, but i can't use my gnome applet for controlling rhythmbox probably because it can't find rhythmbox running as the logged in user. So it might be a permission problem somewhare.
Comment 26 David 2010-04-07 16:22:20 UTC
I am using Linux Mint 8 (based in Ubuntu).
I have the same problem of Rhythmbox crashing if the Remuco plugin is installed,
but running the commands in the Python console does not result in a crash:

>>> qs = shell.props.queue_source

>>> shell.get_player().props.source

<__main__.RBLibrarySource object at 0x30a0e10 (RBLibrarySource at 0x16e0220)>


The same happens for the plugin from repository (version 0.9.9.1) and the package from the project site (version 0.9.2).
The plugin was running fine a week ago or so, and I applied some package updates before having this problem. It's difficult to constrain them by history in Synaptic, since I was using Banshee for some days when I applied them, before going back to use Rhythmbox and find the problem.
With the Rhythmbox Remuco plugin installed from repository I get, consistently:

TypeError: Cannot create a consistent method resolution
order (MRO) for bases Buildable, Orientable, ImplementorIface
**
ERROR:/build/buildd/pygobject-2.18.0/gobject/pygobject.c:924:pygobject_new_full: assertion failed: (tp != NULL)
Aborted
Comment 27 Jonathan Matthew 2011-07-24 23:09:49 UTC
no more static bindings
Comment 28 Oben Sonne 2011-07-25 18:25:36 UTC
Finally .. many thanks :)