Please let us know what version of gstreamer core and gst-python you're using. If it's not the  latest release of both, please re-test using the latest.

also, make sure you have gst-plugins-base (since that's where the interfaces are)

I am using GStreamer 0.10.6 and Base Plugins 0.10.7
and gst-python-0.10.4.

I meet the crash if I import gst in python console.


Current function is pyinterfaces_register_classes
 1534       pyg_register_interface(d, "XOverlay", GST_TYPE_X_OVERLAY,
&PyGstXOve rlay_Type);
(dbx) where
=>[1] pyinterfaces_register_classes(d = 0x81ad57c), line 1534 in "interfaces.c"
  [2] initinterfaces(), line 44 in "interfacesmodule.c"
  [3] _PyImport_LoadDynamicModule(0x80e1ad4, 0x81b0034, 0xfee92040), at
0xfef439 a3


BTW: I am running it on solaris 10 x86.

which version of pygtk and glib do you have ?

glib 2.10.2
pygtk 2.8.6

All these problems are related to modules (C and python) exporting wrong symbols. It should have been fixed in all GStreamer modules (core/gst-plugins-*/gst-python).

Could you try with latest cvs of gstreamer/gst-plugins-base/gst-python.

jerry : ping , could you test with latest pre-release or cvs and confirm that you don't have the issue anymore ?

Closing. If you have the issue again with the new release, re-open.

I just tested this with Jokosher after building and installing the new version of the gst-python bindings (0.10.6).  Still seeing a core dump, though with a slightly different stack trace:

core 'core' of 113795:  python Jokosher/Jokosher
 00000047 ???????? (8366b54)
 c18b332b initinterfaces (8063604, 8044e0c, 843aaac, 1, a, c4e76210) + 5b
 c4f3629b _PyImport_LoadDynamicModule (8044e0c, 804497c, c4e76210) + 83
 c4f34520 load_module (8044e0c, c4e76210, 804497c, 3, 0) + 80
 c4f35407 import_submodule (8061884, 8044e10, 8044e0c) + fb
 c4f34dce load_next (8061884, c4f740d0, 804522c, 8044e0c, 8045220) + a2
 c4f34a2c import_module_ex (0, 82d3c64, 82d3c64, c4f740d0) + 48
 c4f34b55 PyImport_ImportModuleEx (814d1c4, 82d3c64, 82d3c64, c4f740d0) + 1d
 c4f15cea builtin___import__ (0, 8446554) + 4e
 c4ef107f PyCFunction_Call (8069d6c, 8446554, 0) + 15f
 c4ed2375 PyObject_Call (8069d6c, 8446554, 0) + 1d
 c4f20da4 PyEval_CallObjectWithKeywords (8069d6c, 8446554, 0) + b8
 c4f1ce36 PyEval_EvalFrame (833cf44) + d02
 c4f2000a PyEval_EvalCodeEx (843c120, 82d3c64, 82d3c64, 0, 0, 0) + 732
 c4f1c12e PyEval_EvalCode (843c120, 82d3c64, 82d3c64) + 22
 c4f33228 PyImport_ExecCodeModuleEx (80461ac, 843c120, 804543c) + c0
 c4f337ae load_source_module (80461ac, 804543c, c4e76200) + e6
 c4f3454c load_module (80461ac, c4e76200, 80458ac, 1, 0) + ac
 c4f338df load_package (80461ac, 8045d1c) + ef
 c4f3450a load_module (80461ac, 0, 8045d1c, 5, 0) + 6a
 c4f35407 import_submodule (c4f740d0, 80461ac, 80461ac) + fb
 c4f34dce load_next (c4f740d0, c4f740d0, 80465cc, 80461ac, 80465c0) + a2
 c4f34a2c import_module_ex (0, 82d3acc, 82d3acc, c4f740d0) + 48
 c4f34b55 PyImport_ImportModuleEx (80f4eb4, 82d3acc, 82d3acc, c4f740d0) + 1d
 c4f15cea builtin___import__ (0, 82c4d24) + 4e
 c4ef107f PyCFunction_Call (8069d6c, 82c4d24, 0) + 15f
 c4ed2375 PyObject_Call (8069d6c, 82c4d24, 0) + 1d
 c4f20da4 PyEval_CallObjectWithKeywords (8069d6c, 82c4d24, 0) + b8
 c4f1ce36 PyEval_EvalFrame (80c07e4) + d02
 c4f2000a PyEval_EvalCodeEx (84501a0, 82d3acc, 82d3acc, 0, 0, 0) + 732
 c4f1c12e PyEval_EvalCode (84501a0, 82d3acc, 82d3acc) + 22
 c4f33228 PyImport_ExecCodeModuleEx (80470dc, 84501a0, 8046c4c) + c0
 c4f337ae load_source_module (80470dc, 8046c4c, c4e761f0) + e6
 c4f3454c load_module (80470dc, c4e761f0, 8046c4c, 1, 0) + ac
 c4f35407 import_submodule (c4f740d0, 80470dc, 80470dc) + fb
 c4f34dce load_next (c4f740d0, c4f740d0, 80474fc, 80470dc, 80474f0) + a2
 c4f34a2c import_module_ex (0, 0, 0, 0) + 48
 c4f34b55 PyImport_ImportModuleEx (80decb4, 0, 0, 0) + 1d
 c4f15cea builtin___import__ (0, 80873ac) + 4e
 c4ef107f PyCFunction_Call (8069d6c, 80873ac, 0) + 15f
 c4f21302 call_function (8047624, 1) + 406
 c4f1ccd9 PyEval_EvalFrame (8120abc) + ba5
 c4f21408 fast_function (80d8f0c, 8047734, 1, 1, 0) + a8
 c4f20fd6 call_function (8047734, 1) + da
 c4f1ccd9 PyEval_EvalFrame (80a11b4) + ba5
 c4f2000a PyEval_EvalCodeEx (80d9ba0, 8079824, 8079824, 0, 0, 0) + 732
 c4f1c12e PyEval_EvalCode (80d9ba0, 8079824, 8079824) + 22
 c4f3bb35 run_node (80613c8, 8047ae3, 8079824, 8079824, 804798c) + 35
 c4f3baf7 run_err_node (80613c8, 8047ae3, 8079824, 8079824, 804798c) + 1f
 c4f3bace PyRun_FileExFlags (c4e761f0, 8047ae3, 101, 8079824, 8079824, 1) + 5e
 c4f3ae5f PyRun_SimpleFileExFlags (c4e761f0, 8047ae3, 1, 804798c) + 12f
 c4f3a96a PyRun_AnyFileExFlags (c4e761f0, 8047ae3, 1, 804798c) + 56
 c4f4077a Py_Main  (2, 80479d8) + 75a
 08050799 main     (2, 80479d8, 80479e4) + 11
 080506fa _start   (2, 8047adc, 8047ae3, 0, 8047af5, 8047b09) + 7a

Brian, As I said in Comment #6, it's not a gst-python issue, it's related to symbols being exported.
Could you try with latest cvs of gstreamer/gst-plugins-base (and 0.10.6 of gst-python) ?

Oh sorry.  I won't be able to look into this right away.  When will the next gst-plugins-base be released?

They were released about 4 hours ago :) So could you please test with gstreamer and gst-plugins-base 0.10.11 and gst-python 0.10.6.

I updated to GStreamer/plugins-base 0.10.11 and gst-python 0.10.6 and I am sorry to report I am still seeing the same crash.

Created attachment 78391 [details] [review]
fix

The attached patch fixes it for me. I don't understand how gst-python works anywhere without though, which worries me. I think it boils down to a symbol resolution issue, as Edward mentioned, but a symbol resolution issue between the gst-python modules rather than in gstreamer libraries.

Created attachment 78393 [details] [review]
take 2

Sorry, let's try that again, without typing it wrong.

With this patch, and a manual install of python's setuptools I can get Jokosher to launch. It doesn't get very far though - it had problems creating a new project, and it seems to be looking for Alsa devices specifically, instead of probing the available sound backends and finding SunAudio, but these are bugs for the Jokosher guys to look at.

yes, with this patch,
import gst wont crash anymore on solaris x86.

I test it on solaris x86, using gstreamer 0.10.11, gst-py 0.10.6

after I install pygtk, and test some example of gst-py, 
such as using play.py to play some audio or video files

yes, it works.

Question to all those who tried that patch : It seems the problem was in fact fixed upstream in GStreamer core (See bug #391278).

Could you try removing the patch above and trying to see if latest cvs of core fixes the issue ? If so, this bug is a duplicate of the other one.

verified.

Remove the patch and add the patch of bug 391278 , still crash.

no, that's not what I meant. I didn't say to apply the patch of #391278, I said to use cvs of core. The patch commited is not the same as the proposed one.

Indeed, the patch from bug #391278 should not be used. It won't have any effect on Solaris, at least not if Forte is used as compiler.

verified.
After I build gstreamer 0.10.11 from cvs trunk, 
without the patch for this bug, 
import gst will crash.

Re #19: "Question to all those who tried that patch : It seems the problem was in fact fixed upstream in GStreamer core (See bug #391278)."

How are you linking these 2 bugs together at all? Do you have any evidence that the g_thread_init stuff is at all related, or are you just claiming it arbitrarily?

I don't think you're right - I believe the problem is caused by different symbol resolution rules on Solaris, and that it's luck that it works on Linux. It seems to me the extra gobject_init() call needs to be there on Linux too.

how is the patch now?

It fixes the same issue on some MIPS machine. Since this patch doesn't break existing behaviour, it's going in.

2007-03-01  Jan Schmidt  <thaytan@mad.scientist.com>

	reviewed by: Edward Hervey  <edward@fluendo.com>

	* gst/interfacesmodule.c: (initinterfaces):
	initialize pygobject in the gst.interfaces modules. The absence of it
	causes segfaults on Solaris and MIPS machines.
	Fixes #343980