Python crashes if recursively reloading modules

[chrisce]

BPO	742342
Nosy	@tim-one

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2007-03-12.16:51:30.000>
created_at = <Date 2003-05-23.14:03:36.000>
labels = ['interpreter-core']
title = 'Python crashes if recursively reloading modules'
updated_at = <Date 2007-03-12.16:51:30.000>
user = 'https://bugs.python.org/chrisce'

bugs.python.org fields:

activity = <Date 2007-03-12.16:51:30.000>
actor = 'collinwinter'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2003-05-23.14:03:36.000>
creator = 'chris_ce'
dependencies = []
files = []
hgrepos = []
issue_num = 742342
keywords = []
message_count = 6.0
messages = ['16124', '16125', '16126', '16127', '16128', '16129']
nosy_count = 4.0
nosy_names = ['tim.peters', 'jhylton', 'collinwinter', 'chris_ce']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue742342'
versions = ['Python 2.6']

[chrisce]

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.

[jhylton]

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.

[chrisce]

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)

[tim-one]

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.

[chrisce]

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.

[collinwinter]

Fixed in r54291 (trunk), r54294 (release25-maint). Thanks for the bug report, Christian!