Your first example is missing the Gtk initialization call.

If you are referring to Gtk.init, that gets called by the Python overrides on import.

Created attachment 277394 [details]
Example of the crash with everything imported and in the right order

Why did you close this bug? It crashes even with everything included. The point of the first "minimal" example was just to show how the crash is reproducible in a minimal fashion.

Here you have a full example that imports everything and initializes everything (in the right order, reordering did not fix it).

Please note that the crash only occurs in GNOME Classic and other window managers, that are not GNOME Shell.

What is very interesting is that I cannot reproduce this bug when I build the Gtk / Gst stack with cerbero (the GStreamer build system), even when I use the same versions as in Arch Linux.

This could be an Arch Linux / Ubuntu packaging bug, but I would expect more support, or even ideas, from the library developer side.

Created attachment 277395 [details]
stacktrace

I don't understand how a segfault is "NOTABUG" to be honest. A little explanation from whoever closed that report would be welcome :)

Mathieu: In Lionel's defense, it's not obvious that gtk_init() gets called by pygobject while not for any other module. And leaving out initialization often times results in a segfault.

Hi Christophe, no need to defend anyone, I was not in an attacking mood, just asking for more explanation, as I think closing that bug as NOTABUG is incorrect and would like to understand the reasoning behind that.

If as you say, it has been closed because of the absence of the initialization of Gtk, it is indeed not a good reason as, as you pointed out, Gtk is initialized on import by the overrides.

From my investigation at the moment I devised the (admittedly hacky) solution of importing Gdk first, I remember this indeed had to do with ordering of various project's initializations, but the issue only started to show up in pitivi when we started using ClutterGst, which leads me to think part of the problem may be triggered / created by ClutterGst or its potential overrides.

I'm afraid I don't remember much more about the exact issue, but I sure know there is something fishy happening with these various modules' interaction.

If I remember correctly, the whole initialization scheme problem was tackled by someone at that moment (~6 months ago), possibly Simon Feltman.

(In reply to comment #7)
> If I remember correctly, the whole initialization scheme problem was tackled by
> someone at that moment (~6 months ago), possibly Simon Feltman.

Naw, just a passerbyer :)

This gives some of the history: https://bugzilla.gnome.org/show_bug.cgi?id=727851#c7

It might be worth porting the crashing example with correct initialization ordering to Gjs or C to get more traction on solving this...

I was able to reproduce the crash in C. 
https://gist.github.com/lubosz/7af14e62087b6af5f85f

It shows the same behavior as in Python:

* Does not occur in GNOME Shell
* Does not occur when using sudo

In JavaScript though, it does occur always.
https://gist.github.com/lubosz/e01eba5b7ce5240a6219

Funny thing about GJS: Gdk.init also crashes.

This crashes:
#!/usr/bin/env gjs
const Gdk = imports.gi.Gdk;
Gdk.init(ARGV);


Maybe this issue should be reassigned to Gdk?

It's also not a bindings issue, since it crashes in C.

Why I think that the problem is within ClutterGst, is that this minimal JavaScript example crashes when you initialize ClutterGst

https://gist.github.com/lubosz/db4337a39d537f2f6c79

I used JavaScript, since it also crashes in GNOME Shell there. I expect this to crash in C on GNOME Classic.

Here is an example of how to initialize stuff :

https://pastebin.mozilla.org/5291862

I can't remember the details, but the best you can do is getting warnings (instead of crash).

Yes this also does cause warnings for me, but works in JavaScript. 

ClutterGst.init(null);
GtkClutter.init(null);

It also works in C with non GNOME Shell.

clutter_gst_init (&argc, &argv);
gtk_clutter_init(&argc, &argv);

The funny thing is that this does not work when Gtk.init is called.
In Python Gtk.init seems to be called on import.

from gi.repository import Gtk
ClutterGst.init([])
GtkClutter.init([])

So this only works in C and JavaScript.

In GNOME Shell, importing Gdk first fixes the problem.

from gi.repository import Gdk

Switching the initialization of ClutterGst and GtkClutter fixes also the warnings on GNOME Shell. This is how it is done in Pitivi.
But this crashes in non GNOME Shell.

I was able to run the example with warnings in Python (non GNOME Shell), with this import order:

from gi.repository import ClutterGst
ClutterGst.init([])
from gi.repository import GtkClutter
GtkClutter.init([])

from gi.repository import Gdk
from gi.repository import Clutter
from gi.repository import Gst
from gi.repository import Gtk

This also works in Pitivi, but distaches the clutter timeline. For the clutter timeline to be drawn correctly, Pitivi needs to import GtkClutter before ClutterGst.

I've also logged bug 731091 in an effort to have better control over Python import and initialization orderings (among other problems).

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/clutter-gst/-/issues/

Thank you for your understanding and your help.