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 591616 - crashes when creating a new project after loading a project
crashes when creating a new project after loading a project
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal blocker
: 0.13.3
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-12 22:28 UTC by Jean-François Fortin Tam
Modified: 2009-09-05 17:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
GST_DEBUG=3,gnl*:5,*ERR*:5,python:5 PITIVI_DEBUG=5 (156.99 KB, application/x-bzip)
2009-08-12 23:54 UTC, Jean-François Fortin Tam 		Details
PITIVI_DEBUG=*:5 GST_DEBUG=2 (241.89 KB, text/x-log)
2009-08-12 23:56 UTC, Jean-François Fortin Tam 		Details

Description Jean-François Fortin Tam 2009-08-12 22:28:50 UTC 
1. start pitivi
2. load a project
3. click the New button
4. ???
5. Fatal Python error: PyEval_SaveThread: NULL tstate
Abandon
Comment 1 Jean-François Fortin Tam 2009-08-12 23:08:45 UTC 
The same error/symptom also happens when you:
1. start pitivi
2. import a clip, place it in the timeline (optional?)
3. try to load a project
Comment 2 Jean-François Fortin Tam 2009-08-12 23:54:51 UTC 
Created attachment 140603 [details]
GST_DEBUG=3,gnl*:5,*ERR*:5,python:5 PITIVI_DEBUG=5

debug log when crashing when trying to start a Render
Comment 3 Jean-François Fortin Tam 2009-08-12 23:56:04 UTC 
Created attachment 140604 [details]
PITIVI_DEBUG=*:5 GST_DEBUG=2

when crashing after doing a load project followed by "New"
Comment 4 Edward Hervey 2009-08-13 07:25:09 UTC 
I can reproduce the first report (load, new, crash) on jaunty PPA + pitivi git and I get the following backtrace. I only put the top parts, but the rest of the backtrace indicates that this happens when a pipeline is set from PAUSED to READY.

My guess is that the problem lies in gstpad.override:pad_block_destroy_data where we don't re-acquire the GIL after coming from C-land to Python-land.

+ Trace 216907

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libc.so.6
  • #2 abort
    from /lib/tls/i686/cmov/libc.so.6
  • #3 Py_FatalError
    at ../Python/pythonrun.c line 1657
  • #4 PyEval_SaveThread
    at ../Python/ceval.c line 318
  • #5 pygobject_dealloc
    at /build/buildd/pygobject-2.16.1/gobject/pygobject.c line 1075
  • #6 tupledealloc
    at ../Objects/tupleobject.c line 170
  • #7 tupledealloc
    at ../Objects/tupleobject.c line 170
  • #8 pad_block_destroy_data
    at gstpad.override line 1356
  • #9 gst_pad_dispose
    at gstpad.c line 392
  • #10 gst_proxy_pad_dispose
    at gstghostpad.c line 407
  • #11 gst_ghost_pad_dispose
    at gstghostpad.c line 788
  • #12 g_object_unref
    from /usr/lib/libgobject-2.0.so.0
  • #13 pygobject_dealloc
    at /build/buildd/pygobject-2.16.1/gobject/pygobject.c line 1076
  • #14 insertdict
    at ../Objects/dictobject.c line 459
  • #15 PyDict_SetItem
    at ../Objects/dictobject.c line 701
  • #16 PyObject_GenericSetAttr
    at ../Objects/object.c line 1503 






Comment 5


Edward Hervey





          2009-09-05 17:23:11 UTC
        



I can't reproduce this anymore.

Jeff, can you confirm ?






Comment 6


Jean-François Fortin Tam





          2009-09-05 17:29:40 UTC
        



Yes, that one is gone too.