View Issue Details

IDProjectCategoryView StatusLast Update
0001318ScribusScripterpublic2005-04-27 03:49
ReporterringercAssigned Toringerc 
Status closedResolutionnot fixable 
Platformx86 LinuxOSFedora CoreOS Version1
Product Version1.2.1cvs 
Summary0001318: 'Execute Script' crashes Scribus when built against a thread-enabled Python debug build
DescriptionPython debug builds perform some additional checks and tests to 'sanity check' functions. One of these sanity checks aborts due to the way that Scribus creates new interpreters in slotRunScriptFile.

Py_NewInterpreter calls PyThreadState_Swap to swap thread states.

PyThreadState_Swap (Python/pystate.c:265) calls PyGILState_GetThisThreadState to get the thread state for the running thread, and compares it to the thread state that's being switched to. If they're not the same, it aborts the program.

PyGILState_GetThisThreadState appears to use thread-local storage to keep track of the thread state for the thread. I haven't fully unravelled it yet, but that's how it looks.

Note this comment in the PyThreadState_Swap function:

/* It should not be possible for more than one thread state
   to be used for a thread. Check this the best we can in debug+

Python does not check this in single-threaded builds, nor enforce this restriction. Whether this is because it has no way to check and enforce it, or because it doesn't matter, I don't know.

Nonetheless the upshot of all this is that Scribus crashes with a SIGABRT when you try to 'Execute Script' and it has been built against a Python debug build (unless threading was disabled in that Python build).

I can only assume that Python is aborting for a good reason. Perhaps this is related to the PyQt issues that have been so frustrating.

Apache's mod_python may provide some insight, but I haven't been able to make head or tail of what exactly it's doing yet.
TagsNo tags attached.



2004-11-18 06:43

reporter   ~0002898

See this message for some info on the issue.


2004-11-18 07:15

reporter   ~0002899

Last edited: 2004-11-18 07:15

This message describes the issue I'm seeing:*&client=firefox-a&

And here's one answer:

Some more info on multi-threaded embedding:*&client=firefox-a&

Tim Peters speaks up:*&client=firefox-a&

related messages:*&client=firefox-a&

Someone says it's just broken:*&client=firefox-a&

The old thread-sig list:

Discussion about Qt:*


2005-04-19 13:57

reporter   ~0004292

Summary: Looks like we're lucky "Excecute Script" works, because it seems sub interpreters aren't really meant to work unless they have a thread to themselves.

The "Run Extension Script" mode doesn't have this problem (it doesn't use subinterpreters).


2005-04-27 03:48

reporter   ~0004427

I'm going to close this as not fixable. It doesn't seem possible to fix it without spawning threads and using messaging to talk to the app core, or changing Python fairly significantly.

Maybe we could use the threads approach in qt4 when more of Qt is thread safe. Even then, threads largely mean bug-o-rama, and, well, it works now.

Issue History

Date Modified Username Field Change
2004-11-16 11:06 ringerc New Issue
2004-11-18 06:43 ringerc Note Added: 0002898
2004-11-18 07:15 ringerc Note Added: 0002899
2004-11-18 07:15 ringerc Note Edited: 0002899
2005-04-19 13:57 ringerc Note Added: 0004292
2005-04-27 03:44 ringerc Status new => assigned
2005-04-27 03:44 ringerc Assigned To => ringerc
2005-04-27 03:48 ringerc Status assigned => resolved
2005-04-27 03:48 ringerc Resolution open => not fixable
2005-04-27 03:48 ringerc Note Added: 0004427
2005-04-27 03:49 ringerc Status resolved => closed