[Python-bugs-list] [ python-Bugs-742342 ] Python crashes if recursively reloading modules

SourceForge.net noreply@sourceforge.net
Sat, 24 May 2003 02:10:50 -0700


Bugs item #742342, was opened at 2003-05-23 14:03
Message generated for change (Comment added) made by chris_ce
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Eder (chris_ce)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python crashes if recursively reloading modules

Initial Comment:
If one tries to recursively reload modules, python crashes with a 
segfault. e.g. if the file "foo.py" looks something like:
import 
foo
reload (foo)
....

the python interpreter crashes 
when reading this file.

I have been able to reproduce the 
problem both with
python2.2 and python2.3 under 
linux.

Although recursive reloads are faulty code, this 
should lead to an exception but not to a segfault of the 
interpreter.
In our case, this bug allows a faulty user script to 
crash our program.

Sorry if this is already a known bug, but I 
searched in Sorceforge (and also in Google) and did not find 
something similar.


----------------------------------------------------------------------

>Comment By: Christian Eder (chris_ce)
Date: 2003-05-24 09:10

Message:
Logged In: YES 
user_id=785436

You're right, there's nothing wrong with recursive imports
(we also use them in our sources), but with recursive reloads.
As far as I know the import statement reads the module only
if it is not registered in sys.modules. If modules are added
to sys.modules before they are parsed (as I suppose they
are) a recursive import does no harm because the module is
read only once. 
But I think the reload statement re-reads the file
unconditionally (is it so ?) and may therefore cause an
endless recursion.
If the interpreter keeps a graph of files and the relations
which file causes a reading of another file (either by
importing a file which is not yet in sys.modules or by
reloading), situations like recursive reloads could be
easily detected as they would introduce cycles to the graph. 
However this is just an idea, maybe an implementation would
cost too much permance. 
I will research the problem further and notice you if I find
some kind of workaround.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-05-23 18:56

Message:
Logged In: YES 
user_id=31435

The default recursion limit is unconditionally defined -- it 
doesn't vary across platforms.

If you can submit a patch, that would help.  Note that there's 
nothing wrong with (indirectly) recursive imports in Python 
(they're delicate but frequently used anyway), so we can't 
raise an exception on that.

----------------------------------------------------------------------

Comment By: Christian Eder (chris_ce)
Date: 2003-05-23 18:30

Message:
Logged In: YES 
user_id=785436

I tried it on 2 of our development PC's and got the
following results on both of them:
sys.getrecursionlimit ()         ===> 1000
python find_recursionlimit.py ===> 2800

Seems a bit strange, doesn't it ?
I had expected the sys.recursionlimit to be higher than the
actual limit. 

Anyway, recursive reloads are quite easy to detect, so
shouldn't the interpreter detect such statements and raise
an appropriate error exception (not resulting in a maximum
recursion depth exceeded error)

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-23 16:01

Message:
Logged In: YES 
user_id=31392

I expect this is a platform-specific problem with the Python
recursion limit.  Can you report two things?

The value returned by sys.getrecursionlimit(), and
the last limit reported by Misc/find_recursionlimit.py.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470