classification
Title: Python reinitialization test
Type: enhancement Stage:
Components: Build, Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: out of date
Dependencies: Superseder: Python sub-interpreter test
View: 10914
Assigned To: pitrou Nosy List: BreamoreBoy, christian.heimes, loewis, pitrou
Priority: normal Keywords: patch

Created on 2008-01-30 19:10 by christian.heimes, last changed 2012-11-26 20:00 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
test_reinit.patch christian.heimes, 2008-01-30 19:10 review
test_reinit.c christian.heimes, 2008-01-31 13:40
Messages (12)
msg61873 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-30 19:10
The patch adds a new test and a new executable. The executable calls
Py_Initialze() and Py_Finalize() multiple times in a row. The test also
shows that Python looses about 35 references in each round.

$ ./test_reinit
round 1
[7751 refs]
round 2
[7797 refs]
round 3
[7834 refs]
round 4
[7871 refs]
round 5
[7908 refs]
round 6
[7945 refs]
round 7
[7982 refs]
round 8
[8019 refs]
round 9
[8056 refs]
round 10
[8093 refs]
msg61875 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-01-30 19:45
I'm not sure what the purpose of this test is. When would it pass, when
would it fail? I don't think it is a bug if a
Py_Initialize()/Py_Finalize() cycle loses references.
msg61876 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-30 20:07
Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
> 
> I'm not sure what the purpose of this test is. When would it pass, when
> would it fail? I don't think it is a bug if a
> Py_Initialize()/Py_Finalize() cycle loses references.

Today my attempts to fix some reference leaks related to sys.flags and
sys.float_info caused the test to fail. A single init/final cycle worked
but the second cycle broke.

The test also shows an issue in Python 3.0. The double linked reference
list is broken:

$ ./test_reinit
round 1
[24676 refs]
round 2
[25588 refs]
round 3
* ob
object  : <refcnt 0 at 0x82248e8>
type    : str
refcount: 0
address : 0x82248e8
* op->_ob_prev->_ob_next
object  : <refcnt 0 at 0x82248e8>
type    : str
refcount: 0
address : 0x82248e8
* op->_ob_next->_ob_prev
object  : bytearray(b'')
type    : bytearray
refcount: 1
address : 0x839ab98
Fatal Python error: UNREF invalid object
Aborted (core dumped)
msg61895 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-01-31 10:27
Perhaps ROUNDS, CAUSE_SEGFAULT and VERBOSE could be command-line rather
than compile-time options?
msg61899 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-31 13:40
I like to keep the test as simple as possible.

Here is a new file that shows Python crashes in the third Py_Finalize().
msg61904 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-31 15:18
If fixed the problem with multiple reinitialization in r60477. It took
me quite some time to find the right spot.
msg83564 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-03-14 01:34
This is still a good idea.
msg116941 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-20 14:14
Quote msg83564 "This is still a good idea.", in which case shouldn't someone push this forward, failing that close as out of date?
msg116958 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-20 18:07
> Quote msg83564 "This is still a good idea.", in which case shouldn't
> someone push this forward, failing that close as out of date?

Just because someone doesn't "push this forward" doesn't mean it's out of date.
msg126329 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-01-15 13:38
See also #10914.
msg176420 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-26 15:26
Antoine, is the test still required? #10914 has introduced tests for the subinterpreter.
msg176448 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-11-26 20:00
Ah, funny. I ended up doing the same thing as you without remembering about it!
History
Date User Action Args
2012-11-26 20:00:28pitrousetstatus: pending -> closed
superseder: Python sub-interpreter test
messages: + msg176448
2012-11-26 15:26:11christian.heimessetstatus: open -> pending
assignee: pitrou
resolution: out of date
messages: + msg176420
2011-01-15 13:38:47pitrousetnosy: loewis, pitrou, christian.heimes, BreamoreBoy
messages: + msg126329
2010-09-20 18:07:14pitrousetmessages: + msg116958
2010-09-20 14:14:58BreamoreBoysetnosy: + BreamoreBoy
messages: + msg116941
2010-07-10 06:24:22terry.reedysetversions: + Python 3.2, - Python 2.6, Python 3.0
2009-03-14 01:34:27pitrousetmessages: + msg83564
2008-01-31 15:18:19christian.heimessetmessages: + msg61904
2008-01-31 13:40:40christian.heimessetfiles: + test_reinit.c
messages: + msg61899
2008-01-31 10:27:24pitrousetnosy: + pitrou
messages: + msg61895
2008-01-30 20:07:50christian.heimessetmessages: + msg61876
2008-01-30 19:45:11loewissetnosy: + loewis
messages: + msg61875
2008-01-30 19:10:43christian.heimescreate