[issue1225584] crash in gcmodule.c on python reinitialization

[Terry J. Reedy]

Terry J. Reedy added the comment:

I am closing since the initial problem has been fixed and there is no known 
current problem to fix.  If someone does discover one, they can reopen or, 
probably better, open a new issue.

--
resolution:  -> fixed
stage: test needed -> resolved
status: languishing -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Antoine Pitrou]

Antoine Pitrou added the comment:

Someone interested in this issue should first check whether it still applies to 
3.4 or 3.5.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Nick Coghlan]

Nick Coghlan added the comment:

I don't actually know the internal details of the GC - adding Antoine based on 
the list of interested devs for the gc module.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Terry J. Reedy]

Terry J. Reedy added the comment:

Nick, please read my previous msg if you can find a moment.

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Terry J. Reedy]

Terry J. Reedy added the comment:

The initial test case was apparently fixed. It is not clear to me that the 
second, msg57834, is a supported use case. Nick, I know you are busy, but there 
is no C api category in the experts list. Any comment?

Unless someone can identify a bug in current 2.7 or 3.4+ or propose an 
enhancement for 3.5, we should close this. gc has been enhanced since 2.4, 2.5, 
and I would not expect anything said about those versions to apply to 3.4+.

--
stage:  -> test needed
type:  -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Mark Lawrence]

Mark Lawrence added the comment:

I find it surprising that something flagged up as causing a crash hasn't had a 
little more TLC, but is this still a genuine problem?

--
components: +Windows
nosy: +BreamoreBoy, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Christian Heimes]

Changes by Christian Heimes:


--
versions: +Python 2.5, Python 2.6

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Adam Olsen]

Adam Olsen added the comment:

mwh, my threading patch is extensive enough and has enough overlap that
I'm not intimidating by fixing this.  It's low on my list of priorities
though.

So far my tendency is to rip out multiple interpreters, as I haven't
seen what it wants to accomplish.  It's certainly *NOT* completely
isolated interpreters.

As for Py_Finalize, I see 4 purposes to calling it:
1) Finish any lingering bits of the program, such as __del__ methods or
weakref callbacks
2) Delete lingering references so refcount errors or memory leaks may be
more easily discovered
3) Prepare for Py_Initialize to be called again
4) Return the interpreter to a quiescent state such that python.so can
be safely unloaded, then reloaded and Py_Initialize called again

Of these, 3 and 4 are not done.  3 would be easy if Py_Finalize was a
no-op, but that'd undermine 1 and 2.  Given the optimistic
documentation, it's surprising how limited Py_Finalize's scope is.

I've seen some fleeting discussion of allowing extension modules to be
unloaded, which IMO requires returning them to a quiescent state.  Doing
that may lay the foundation for doing it to the entire interpreter.

Anyway, real use cases are critical here.  Although you may think you
want your plugins to unload python, the costs mean you should only do so
very rarely, enough that there's really no advantage to unloading it
(except at program shutdown, for purposes 1 and 2.)

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[Adam Olsen]

Changes by Adam Olsen:


--
nosy: +rhamphoryncus

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1225584] crash in gcmodule.c on python reinitialization

[ita]

ita added the comment:

The following still crashes (python 2.5.1):

for (int i=0; i<1000; ++i)
{
Py_Initialize();
PyRun_SimpleString("import tarfile\n");
Py_Finalize();
}

Bindings such as Swig are adding weird hacks just for avoiding the
finalize call and resetting the variables. Not being able to start from
a clean interpreter is unacceptable.

--
nosy: +ita

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com