[ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization
Bugs item #1225584, was opened at 2005-06-22 16:43
Message generated for change (Comment added) made by amiseler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash in gcmodule.c on python reinitialization
Initial Comment:
i have a c++ windows application with embedded python
interpreter.
this code crashs:
Py_Initialize();
PyRun_SimpleString("import gc");
Py_Finalize();
Py_Initialize();
PyRun_SimpleString("import gc");// <--- BOOM
the problem seems to be the global var "garbage" in
gcmodule.c
the var isn't cleared in the reinitialization and
becomes an invalid pointer.
setting it to NULL in Py_Finalize fixes the crash.
i use python version 2.3.4 but a short look at the
2.4.1 source indicates that the problem is still there.
--
>Comment By: Alexander Miseler (amiseler)
Date: 2005-06-23 10:11
Message:
Logged In: YES
user_id=693638
yes, Neil Schemenauer (nascheme) added a Py_INCREF(garbage)
to initgc.
that *MIGHT* fix the crash. but only by simply never
releasing the garbage list. the garbage variable is still
never reset to NULL and therefore no new garbage list is
created after reinitialization.
besides: the incref is only in gcinit, but the list can be
created in gcinit OR in handle_finalizers (and while i was
looking at it in the debugger it always was handle_finalizers).
i guess the proper way to fix it would be a cleanup function
for the gcmodule that is called by Py_Finalize. the cleanup
function should do a decref (if Neils incref stays in, i'm
not sure if it is needed) and then reset the global vars.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-22 17:59
Message:
Logged In: YES
user_id=6656
Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you
in a position to check that?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization
Bugs item #1225584, was opened at 2005-06-22 15:43
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
>Assigned to: Neil Schemenauer (nascheme)
Summary: crash in gcmodule.c on python reinitialization
Initial Comment:
i have a c++ windows application with embedded python
interpreter.
this code crashs:
Py_Initialize();
PyRun_SimpleString("import gc");
Py_Finalize();
Py_Initialize();
PyRun_SimpleString("import gc");// <--- BOOM
the problem seems to be the global var "garbage" in
gcmodule.c
the var isn't cleared in the reinitialization and
becomes an invalid pointer.
setting it to NULL in Py_Finalize fixes the crash.
i use python version 2.3.4 but a short look at the
2.4.1 source indicates that the problem is still there.
--
>Comment By: Michael Hudson (mwh)
Date: 2005-06-23 09:22
Message:
Logged In: YES
user_id=6656
At this point you might be thinking that Py_NewInterpreter/
Py_EndInterpreter loops are not the best tested things in the world. You'd
be right.
Neil's fix *does* fix the crash, but also shares PyObject's between
interpreter states, which is a bit of a no-no, but otoh, this problem is far
from unique to gcmodule.c.
> besides: the incref is only in gcinit, but the list can be
> created in gcinit OR in handle_finalizers (and while i was
> looking at it in the debugger it always was handle_finalizers).
That slightly misses the point -- the reason you got a crash was because
the PyModule_AddObject initgc stole a reference to garbage, so when the
module got cleaned up, it got deallocated despite there still being a
reference to it in the module level global. If initgc is never run, the
refcount of garbage stays at 1.
> i guess the proper way to fix it would be a cleanup function
> for the gcmodule that is called by Py_Finalize.
Yeah, but quite a lot of modules could do with that, I think. Do you have
the energy to work on a 'proper' solution? I don't.
--
Comment By: Alexander Miseler (amiseler)
Date: 2005-06-23 09:11
Message:
Logged In: YES
user_id=693638
yes, Neil Schemenauer (nascheme) added a Py_INCREF(garbage)
to initgc.
that *MIGHT* fix the crash. but only by simply never
releasing the garbage list. the garbage variable is still
never reset to NULL and therefore no new garbage list is
created after reinitialization.
besides: the incref is only in gcinit, but the list can be
created in gcinit OR in handle_finalizers (and while i was
looking at it in the debugger it always was handle_finalizers).
i guess the proper way to fix it would be a cleanup function
for the gcmodule that is called by Py_Finalize. the cleanup
function should do a decref (if Neils incref stays in, i'm
not sure if it is needed) and then reset the global vars.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-22 16:59
Message:
Logged In: YES
user_id=6656
Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you
in a position to check that?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224672 ] rsplit introduces spurious CR
Bugs item #1224672, was opened at 2005-06-21 07:47 Message generated for change (Comment added) made by rprosser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. -- >Comment By: Richard Prosser (rprosser) Date: 2005-06-23 09:15 Message: Logged In: YES user_id=599403 False alarm - Unix issues CR/LF sequence with a tty appararently, and I am using ssh with pexpect. I have confirmed this via 'od'. See http://pexpect.sourceforge.net/ for details. Apologies. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 07:58 Message: Logged In: YES user_id=80475 Please submit a test case reduced to one line: "somestring".rsplit() # introduces \r not present in input -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224672 ] rsplit introduces spurious CR
Bugs item #1224672, was opened at 2005-06-21 09:47 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 12:03 Message: Logged In: YES user_id=1188172 Closing as Invalid, then. -- Comment By: Richard Prosser (rprosser) Date: 2005-06-23 11:15 Message: Logged In: YES user_id=599403 False alarm - Unix issues CR/LF sequence with a tty appararently, and I am using ssh with pexpect. I have confirmed this via 'od'. See http://pexpect.sourceforge.net/ for details. Apologies. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 09:58 Message: Logged In: YES user_id=80475 Please submit a test case reduced to one line: "somestring".rsplit() # introduces \r not present in input -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1041501 ] SimpleXMLRPCServer example is broken
Bugs item #1041501, was opened at 2004-10-06 14:31 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041501&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer example is broken Initial Comment: Section 11.21.1 of the library reference (SimpleXMLRPCServer Objects) includes this class definition: class MyFuncs: def div(self, x, y) : return div(x,y) This is given to the sample server as in instance object. The problem is that there is no global div() function so attempting to call div() from XML-RPC returns a Fault with a NameError. -- >Comment By: Kent Johnson (kjohnson) Date: 2005-06-23 12:39 Message: Logged In: YES user_id=49695 Reopened because a similar fix is needed on the page 11.23.2 CGIXMLRPCRequestHandler -- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-08 18:34 Message: Logged In: YES user_id=11375 Fixed; thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1041501&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1226256 ] Add Jason Orendorff's path module to stdlib
Feature Requests item #1226256, was opened at 2005-06-23 13: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=1226256&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Add Jason Orendorff's path module to stdlib Initial Comment: Jason Orendorff has produced an excellent path module which has an OOP approach to path, directory, and file manipulation, as well as including some new convenience functions. In my opinion, it allows much more Pythonic path manipulation than the functions in os and os.path. It is quite stable and includes unit tests. I and many others have been using it for years. http://www.jorendorff.com/articles/python/path/ I am requesting that it be added to the stdlib. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1226256&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
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: Peter Åstrand (astrand)
Date: 2005-06-23 18:03
Message:
Logged In: YES
user_id=344921
I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?
--
Comment By: cheops (atila-cheops)
Date: 2005-05-12 12: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-1180160 ] subprocess.Popen fails with closed stdout
Bugs item #1180160, was opened at 2005-04-10 13:41 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180160&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: neuhauser (neuhauser) Assigned to: Peter Åstrand (astrand) Summary: subprocess.Popen fails with closed stdout Initial Comment: I have a piece of code that gets run in a script that has its stdout closed: import sys sys.stdout = sys.stderr c = subprocess.Popen (..., stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.STDOUT) and this is what I get: SendingSVNR/permissions Transmitting file data .svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Traceback (most recent call last): (...) File ".../__init__.py", line 40, in run stderr = subprocess.STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 554, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 986, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory This is the child_traceback: File "/usr/local/lib/python2.4/subprocess.py", line 955, in _execute_child File "/usr/local/lib/python2.4/os.py", line 341, in execvp File "/usr/local/lib/python2.4/os.py", line 379, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory http://docs.python.org/lib/node230.html claims that "PIPE indicates that a new pipe to the child should be created" which doesn't seem to be the case. Subversion code that runs the script can be seen at http://svn.collab.net/viewcvs/svn/trunk/subversion/libsvn_repos/hooks.c (run_hook_cmd()). -- >Comment By: Peter Åstrand (astrand) Date: 2005-06-23 18:05 Message: Logged In: YES user_id=344921 No response in over 2 months. Closing. -- Comment By: Peter Åstrand (astrand) Date: 2005-04-14 21:26 Message: Logged In: YES user_id=344921 I can't se anything in your report that indicates that a closed stdout is the problem. execvp() says "No such file or directory", which means that the file you are trying to execute doesn't exist. Do you have any reason to believe that this error message is not true? It would help if you could give me a working *Python* example, indicating the problem. The source http://svn.collab.net/viewcvs/svn/trunk/subversion/libsvn_repos/hooks.c is written in C, not Python... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226404 ] Can't take sequence slice past 32K
Bugs item #1226404, was opened at 2005-06-23 13:30 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=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226404 ] Can't take sequence slice past 32K
Bugs item #1226404, was opened at 2005-06-23 19:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 19:36 Message: Logged In: YES user_id=1188172 Did you actually try this with "indices" below 32k? It won't work there, either. Reason: The syntax for slices is x[y:z], not x[y,z]. The latter calls __getitem__ with the tuple (y,z) as the second argument. Closing as Invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226404 ] Can't take sequence slice past 32K
Bugs item #1226404, was opened at 2005-06-23 13:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. -- >Comment By: Tim Peters (tim_one) Date: 2005-06-23 13:36 Message: Logged In: YES user_id=31435 Something's confused here. x[y, z] doesn't ask for a slice, it's trying to index x by the two-tuple (y, z). x[y:z] (with a colon) is the way to ask for a slice. I don't have any trouble with slice notation regardless of how large the slice bounds are, but of course a sequence complains if you try to index it with a tuple. >>> x = 'spam' * 16000 >>> len(x[34000:34100]) # slice notation 100 >>> len(x[34000, 34100]) # trying to index with a tuple Traceback (most recent call last): File "", line 1, in ? TypeError: string indices must be integers Is that all there is to this? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 13:36 Message: Logged In: YES user_id=1188172 Did you actually try this with "indices" below 32k? It won't work there, either. Reason: The syntax for slices is x[y:z], not x[y,z]. The latter calls __getitem__ with the tuple (y,z) as the second argument. Closing as Invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1226404 ] Can't take sequence slice past 32K
Bugs item #1226404, was opened at 2005-06-23 18:30 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Nobody/Anonymous (nobody) Summary: Can't take sequence slice past 32K Initial Comment: If you have a string/list/etc longer than 32K and you attempt to take a slice beyond the 32K size, you get "TypeError: indices must be integers". For example, if x='spam'*16000, then something like x[34000, 34100] fails, and x[y, z] also fails if y=34000 and z=34100 It affects lists and tuples as well as strings. This is present in 2.4 and 2.4.1, and happens on at least the Linux and Windows platforms. -- >Comment By: Michael Hudson (mwh) Date: 2005-06-23 18:49 Message: Logged In: YES user_id=6656 Battle of the dueling updates! -- Comment By: Tim Peters (tim_one) Date: 2005-06-23 18:36 Message: Logged In: YES user_id=31435 Something's confused here. x[y, z] doesn't ask for a slice, it's trying to index x by the two-tuple (y, z). x[y:z] (with a colon) is the way to ask for a slice. I don't have any trouble with slice notation regardless of how large the slice bounds are, but of course a sequence complains if you try to index it with a tuple. >>> x = 'spam' * 16000 >>> len(x[34000:34100]) # slice notation 100 >>> len(x[34000, 34100]) # trying to index with a tuple Traceback (most recent call last): File "", line 1, in ? TypeError: string indices must be integers Is that all there is to this? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-23 18:36 Message: Logged In: YES user_id=1188172 Did you actually try this with "indices" below 32k? It won't work there, either. Reason: The syntax for slices is x[y:z], not x[y,z]. The latter calls __getitem__ with the tuple (y,z) as the second argument. Closing as Invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1226404&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225584 ] crash in gcmodule.c on python reinitialization
Bugs item #1225584, was opened at 2005-06-22 14:43
Message generated for change (Comment added) made by nascheme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Neil Schemenauer (nascheme)
Summary: crash in gcmodule.c on python reinitialization
Initial Comment:
i have a c++ windows application with embedded python
interpreter.
this code crashs:
Py_Initialize();
PyRun_SimpleString("import gc");
Py_Finalize();
Py_Initialize();
PyRun_SimpleString("import gc");// <--- BOOM
the problem seems to be the global var "garbage" in
gcmodule.c
the var isn't cleared in the reinitialization and
becomes an invalid pointer.
setting it to NULL in Py_Finalize fixes the crash.
i use python version 2.3.4 but a short look at the
2.4.1 source indicates that the problem is still there.
--
>Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-23 18:34
Message:
Logged In: YES
user_id=35752
Well, the fact that some things are broken is not a good
excuse to introduce more brokeness. I guess decrefing the
gc.garbage list and letting any reference cycles contained
in it leak is better than sharing objects between interpreters.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-23 08:22
Message:
Logged In: YES
user_id=6656
At this point you might be thinking that Py_NewInterpreter/
Py_EndInterpreter loops are not the best tested things in the world. You'd
be right.
Neil's fix *does* fix the crash, but also shares PyObject's between
interpreter states, which is a bit of a no-no, but otoh, this problem is far
from unique to gcmodule.c.
> besides: the incref is only in gcinit, but the list can be
> created in gcinit OR in handle_finalizers (and while i was
> looking at it in the debugger it always was handle_finalizers).
That slightly misses the point -- the reason you got a crash was because
the PyModule_AddObject initgc stole a reference to garbage, so when the
module got cleaned up, it got deallocated despite there still being a
reference to it in the module level global. If initgc is never run, the
refcount of garbage stays at 1.
> i guess the proper way to fix it would be a cleanup function
> for the gcmodule that is called by Py_Finalize.
Yeah, but quite a lot of modules could do with that, I think. Do you have
the energy to work on a 'proper' solution? I don't.
--
Comment By: Alexander Miseler (amiseler)
Date: 2005-06-23 08:11
Message:
Logged In: YES
user_id=693638
yes, Neil Schemenauer (nascheme) added a Py_INCREF(garbage)
to initgc.
that *MIGHT* fix the crash. but only by simply never
releasing the garbage list. the garbage variable is still
never reset to NULL and therefore no new garbage list is
created after reinitialization.
besides: the incref is only in gcinit, but the list can be
created in gcinit OR in handle_finalizers (and while i was
looking at it in the debugger it always was handle_finalizers).
i guess the proper way to fix it would be a cleanup function
for the gcmodule that is called by Py_Finalize. the cleanup
function should do a decref (if Neils incref stays in, i'm
not sure if it is needed) and then reset the global vars.
--
Comment By: Michael Hudson (mwh)
Date: 2005-06-22 15:59
Message:
Logged In: YES
user_id=6656
Bizarrely, I think this got fixed in CVS HEAD just a few days ago. Are you
in a position to check that?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225584&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
