[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None >Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? -- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. -- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). -- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:39 Message: Logged In: YES user_id=1218811 Here's the updated threadmodule.c for 2.4.1 -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 13:36 Message: Logged In: YES user_id=1218811 I've finally got access to a C compiler and it looks like the 'pure' Python changes for #754449 are in the clear (apologies to bcannon). The problem actually seems to relate to changes to threadmodule.c of the Python Modules directory. In versions greater than 2.3.4 it
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 08:56 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: Michael Hudson (mwh) Date: 2005-05-12 08:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? -- Comment By: anothermax (yetanothermax) Date: 2005-05-12 08:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? -- Comment By: anothermax (yetanothermax) Date: 2005-04-21 13:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. -- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 06:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). -- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 04:11 Message: Logged In: YES user_id=14198 Can anyone tell me specifically what Python C API function is involved here? ie, the "entry point" that these external threads use to call into Python. -- Comment By: anothermax (yetanothermax) Date: 2005-04-20 12:51 Message: Logged In: YES user_id=1218811 I didn't see jbelmote's comment, perhaps my updated threadmodule.c will reopen the #1010677 bug. -- Com
[ python-Bugs-1163563 ] Sub threads execute in restricted mode
Bugs item #1163563, was opened at 2005-03-15 09:56 Message generated for change (Comment added) made by yetanothermax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: anothermax (yetanothermax) Assigned to: Nobody/Anonymous (nobody) Summary: Sub threads execute in restricted mode Initial Comment: I'm using the JEP product which allows integration of Java with Python (see http://jepp.sourceforge.net) via starting a Python interpreter in the same process as the JVM. This integrates with python via the C interface, allowing the user to 'eval' python code (amongst other features). It seems that since Python 2.3.5 any threads (using the threading module) created via code that has been evaluated through the jep.eval() interface (i.e.Python C interface )are executed in restricted mode and cannot, for example, create files. Code that is just evaled (i.e not in a subthread) thread has no restrictions. The error reported is: IOError: file() constructor not accessible in restricted mode (see http://sourceforge.net/forum/forum.php? thread_id=1247793&forum_id=376782) - I've given a JEP specific example here. There seems to be a similar problem with mod_python (see http://www.modpython.org/pipermail/mod_python/2005- January/017129.html) Reading through the release notes for Python 2.3.5 I see: Bug #754449: threading.Thread will no longer mask exceptions raised during interpreter shutdown with another exception caused by attempting to output the initial exception. This fix also includes a backport of rev. 1.41 from HEAD. This might be the problem as it seems to involve the porting of 2.4 threading code back to the 2.3 tree. I've attached a Java file which shows the problem when using JEP. The error output is: Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\Lib\threading.py", line 442, in __bootstrap File "", line 5, in run IOError: file() constructor not accessible in restricted mode 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] Creating file from main thread... Done Creating file from sub thread... Done -- >Comment By: anothermax (yetanothermax) Date: 2005-05-12 10:48 Message: Logged In: YES user_id=1218811 It looks like with Python versions > 2.3.4 threads are off limits for multiple interpreters. If that's your definition of screwed then I guess the answer's yes. I'm surprised more mod_python users haven't been bitten by this. Shall I raise theproblem on the list (I've already done so on comp.lang.python a while ago) -- Comment By: Michael Hudson (mwh) Date: 2005-05-12 09:43 Message: Logged In: YES user_id=6656 I saw the subject and thought "Hmm, should raise the priority of this so it gets at least thought about hard by the next release", then saw that you did that... > How do we get this solved for the next Python release? I don't know. It's possible it should be raised on python-dev (it seems fairly quiet just now, so it might be a good time :). Basically, it seems that the whole multiple interpreters facility is screwed, correct? -- Comment By: anothermax (yetanothermax) Date: 2005-05-12 09:35 Message: Logged In: YES user_id=1218811 This problem prevents us from upgrading to Python 2.4. I've attached a another 'fixed' threadmodule.c which is based upon the lastest CVS release.(Only change from the last threadmodule.c attachment is the removal of a '\n' from an error message). The threadtest.c program demonstrates the problem (seems to be the use of Py_NewInterpreter() with the PyGIL_StateXXX functions in the current threadmodule.c). How do we get this solved for the next Python release? -- Comment By: anothermax (yetanothermax) Date: 2005-04-21 14:05 Message: Logged In: YES user_id=1218811 I've attached a file (threadtest.c) that is adapted from the the way JEP uses Py_NewInterpreter. This runs correctly under 2.3.4 but fails under 2.3.5 and later Pythons. -- Comment By: mrjohnson (mrjohnson0) Date: 2005-04-21 07:51 Message: Logged In: YES user_id=1044885 In interactive mode, Jep uses Py_NewInterpreter, Py_CompileString, and PyRun_String for its eval(). This file handles java -> python: http://204.156.146.230/cgi-bin/viewcvs.cgi/jep/pyembed.c?rev=1.29&content-type=text/vnd.viewcvs-markup You'd be looking for pyembed_eval(). -- Comment By: Mark Hammond (mhammond) Date: 2005-04-21 05:11 Message: Logged In: YES user_id=14
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', stdin=None,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
>Comment By: cheops (atila-cheops)
Date: 2005-05-12 10:17
Message:
Logged In: YES
user_id=1276121
this might be related to bug 1183780
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files
Bugs item #1200686, was opened at 2005-05-12 16:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: SyntaxError raised on win32 for correct files
Initial Comment:
Try to import the attached file (dt.py) on Windows with
Python 2.4 or 2.4.1 and you'll get a SyntaxError (the
file was written a long time ago, and worked perfectly
well on Python 2.1, 2.2 and 2.3.) The same does not
happen when importing the same module on Linux (tested
with 2.4 and 2.4.1). When the module imports fine
you'll get an ImportError (don't want to attach all
dependencies here) but the SyntaxError comes before that.
Also note that compiling the file with
compiler.compileFile("dt.py") generates a perfectly
good .pyc file that can be later imported just fine
(tested with 2.4 and 2.4.1 on Windows).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1195984 ] SystemError: error return without exception set
Bugs item #1195984, was opened at 2005-05-05 11:38 Message generated for change (Comment added) made by nbajpai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError: error return without exception set Initial Comment: I am getting following error with Python 2.4.1 relase: "SystemError: error return without exception set" my code works fine with earlier release (python 2.4). Its a C code build in python so does not leave much traces to describe problem more. Important Notes: Release name: 2.4.1(final) Platform: Solaris 2.8 Error: "SystemError: error return without exception set" -- >Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-12 10:34 Message: Logged In: YES user_id=1165734 Agree with the comments made. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-11 19:07 Message: Logged In: YES user_id=593130 When people mix their own C code with CPython and get a SystemError like this, the probability that the error is in the added code and not the core code is perhaps greater than .95. Please consider closing this report as invalid unless and until you have evidence that the problem is indeed in the core code. To get help reviewing your added code, you can post to comp.lang.python, the general Python mailing list (python.org), or gmane.comp.python.general (gmane.org). To me, the Python error message seems meaningful enough. It seems to claim that you made an error return without setting an exception according to the rules of the C API. -- Comment By: Michael Hudson (mwh) Date: 2005-05-10 09:52 Message: Logged In: YES user_id=6656 Are you writing your own C code? If so, why do you suspect a bug in Python itself? (Also, a debug build of python can be useful for this sort of thing). -- Comment By: Niraj Bajpai (nbajpai) Date: 2005-05-10 09:50 Message: Logged In: YES user_id=1165734 Actually the same error happens in both 2.4 and 2.4.1. I call in python code to receive events from C code embedded in python interpreter. There are two meaningful events and idle event. I commented idle event in the code (C-code) and start seeing this error. from python code: x.receive(A) << Error happens here where A can be , receive "X" or receive "Y" or receive "NOTHING" In C code when I comment "NOTHING" event generator, I get the error. Some meaningful exception in python would have been better. -- Comment By: Michael Hudson (mwh) Date: 2005-05-06 07:45 Message: Logged In: YES user_id=6656 Uh, there's not a lot to go on here. Can you post some code? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-834351 ] Mouse wheel crashes program
Bugs item #834351, was opened at 2003-11-02 00:37
Message generated for change (Comment added) made by orthorim
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470
Category: Tkinter
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Richardson (garyrxx)
Assigned to: Martin v. Löwis (loewis)
Summary: Mouse wheel crashes program
Initial Comment:
The following program (by Michael Peuser) crashes as
soon as the mouse wheel is moved. See my post to
c.l.p. on Oct 29.
Gary Richardson
#-
from Tkinter import *
def _onMouseWheel(event):
print event
root = Tk()
root.bind('',_onMouseWheel)
root.mainloop()
--
Comment By: nikolaus heger (orthorim)
Date: 2005-05-12 14:41
Message:
Logged In: YES
user_id=933256
sdati, thanks for this workaround. it's awesome. i am now
happily mouse-wheeling :)
I did make a small improvement to it so it works for all
MouseWheel type events. Instead of
if sequence == "":
i say
if type(sequence) == str and
sequence.__contains__("MouseWheel"):
This way, all permutations of mouse events are covered, e.g.
""
--
Comment By: Steve Davis (sdati)
Date: 2005-02-08 02:40
Message:
Logged In: YES
user_id=1214285
I have determined the root cause of this problem. It actually does lie in
Tk, but is only revealed by Python Tkinter because of the way Python
deals with events.
>From Tk source -- tkWinX.c:
case WM_MOUSEWHEEL:
...
event.xany.send_event = -1
...
This line causes Tk to call TkpGetString() when ExpandPercents() is
called with '%A' (which is done by Python for ALL events, including
). This, in turn, causes segmentation fault because
event.xkey.trans_chars and event.xkey.nbytes are not initialized.
So, the workaround from the Python side is pretty ugly, but I have
tested it and verified that it works. There is probably a better way, but
this was the obvious solution to me, since I have never needed to look at
the Tkinter interface before:
In Tkinter.py, define a new _subst_format and _subst_format_str:
_subst_format_workaround = ('%#', '%b', '%f', '%h', '%k',
'%s', '%t', '%w', '%x', '%y',
'%D', '%E', '%K', '%N', '%W', '%T', '%X', '%Y', '%D')
_subst_format_str_workaround = " ".join(_subst_format_workaround)
Note that '%A' entry in _subst_format is replaced with '%D' entry in
_subst_format_workaround.
Now, in Misc._bind(),
if sequence == "":
cmd = ('%sif {"[%s %s]" == "break"} break\n'
%
(add and '+' or '',
funcid, self._subst_format_str_workaround))
else:
cmd = ('%sif {"[%s %s]" == "break"} break\n'
%
(add and '+' or '',
funcid, self._subst_format_str))
I am submitting this bug to Tcl/Tk maintainers to request that they fix
(Project: Tk Toolkit Request ID 1118340), but in the meantime (and for
all older versions of Tk), it seems like a workaround in the Tkinter code
might be appropriate.
--
Comment By: John Speno (corvus)
Date: 2005-01-04 15:40
Message:
Logged In: YES
user_id=2138
I wasn't able to reproduce this in pure Tcl/Tk (under Wish). No surprise
there. In wish, I used this:
toplevel .top
bind .top {puts 'foo'}
And mouse wheeling in the Toplevel widget made a bunch of 'foo's appear in
the wish console without crashing.
HTH.
--
Comment By: John Speno (corvus)
Date: 2005-01-04 15:02
Message:
Logged In: YES
user_id=2138
Me too. Python 2.3.4 with Tcl/Tk 8.4.9. Crash on Scroll Wheeling in WinXP
SP 1. (users report it happening in SP 2 also).
I'll try to make this happen in pure Tcl/Tk rather than Tkinter too.
--
Comment By: John Fouhy (johnfouhy)
Date: 2004-10-26 04:13
Message:
Logged In: YES
user_id=1084032
I can reproduce this bug. I am running Python 2.3.4 on
WinXP SP2.
tk84.dll is version 8.4.3; tcl84.dll is also 8.4.3.
The mousewheel works correctly with a Tkinter.Text object
with no additional bindings.
--
Comment By: Jon Ashley (ash101)
Date: 2003-12-04 17:02
Message:
Logged In: YES
user_id=923903
Happens for me too, on Win2K with python 2.3.2. The fault is
in TCL84.DLL at an offset of 1002a58c, if that means
anything to anyone.
--
Comment By: Gary Richardson (garyrxx)
Date: 2003-11-03 02:42
Message:
Logged In: YES
user_id=899035
I'm using Win98SE.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-11-02 18:37
Message:
Logged In: YES
[ python-Feature Requests-1200804 ] enhancing os.chown functionality
Feature Requests item #1200804, was opened at 2005-05-12 16:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
