[ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault

[SourceForge.net]

Bugs item #780714, was opened at 2003-07-31 10:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&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.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Stefan Gregory (stefan_gregory)
Assigned to: Nobody/Anonymous (nobody)
Summary: infinite __str__ recursion in thread causes seg fault

Initial Comment:
The following code reliably produces a segmentation
fault under Solaris8 in Python2.3, Python2.2,
Python2.1.3 and Python1.5. It produces a Bus Error when
run on Python2.2 under OSX. Clearly it should produce a
Python RuntimeError.

import thread, time

class Frog:

    def __str__(self):
        return str(self)

f = Frog()
thread.start_new_thread(str,(f,))
time.sleep(1000)

This problem manifests in scenarios such as when you
have 2 publishing objects (such as HTMLgen objects) A
and B and you put A inside B and B inside A and each
objects __str__ method calls its childrens __str__
methods and voila! (I hope this might be the reason my
Zope server has been intermitently crashing for the
past year or so though I have not found any recursive
structures yet.)

With Python2.3 gdb reports:

vgetargskeywords (args=0x1bdaf0, keywords=0x0,
format=0xd2579 "0:str", kwlist=0xf7b4c,
p_va=0xfed0C02c) at Python/getargs.c:1167

Though with Python2.1 it dies at line 330 in getargs.c.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 02:03

Message:
Logged In: YES 
user_id=21627

I fail to see the problem. You have to change the recursion
limit; if you do, you risk a crash, as the documentation says:

http://docs.python.org/lib/module-sys.html
"This should be done with care, because a too-high limit can
lead to a crash."

With an unmodified recursionlimit in 2.4.3 on Windows, I get
the expected RuntimeError. If it causes a crash on some
system, it just means that the default recursion limit is
too high for that platform (however, we don't seem to have a
confirmation that the default recursion limit is too large
for this application on any platform for Python 2.4 or 2.5).

It is quite common that the system provides the main thread
with a larger stack space than any additional thread, so it
is not surprising that the stack overflow is detected on
some system when the code is run in the main thread, yet
crashes in an additional thread. The default recursion limit
should be the conservative minimum of what the system
minimally guarantees for any thread.

It seems that the original problem has been fixed (although
nobody apparently has tested Python 2.4 or 2.5 on Solaris8);
I suggest to close this as fixed again.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-08-16 09:42

Message:
Logged In: YES 
user_id=341410

>>> import sys
>>> sys.setrecursionlimit(10000)
>>> class foo:
...     def __str__(self):
...             return str(self)
...
>>> import threading
>>> threading.Thread(target=foo().__str__).start()

Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux
(I can't test 2.5 on linux).  Running in the main thread on
Windows doesn't seem to be a big deal:

>>> import sys
>>> sys.setrecursionlimit(10000)
>>> class foo:
...     def __str__(self):
...             return str(self)
...
>>> try:
...     str(foo())
... except Exception, why:
...     print why
...
Stack overflow
>>>

Note that the above crashes 2.3 and 2.4 on Linux.

This is still a bug, at least in maintenance on 2.4. 
Suggested reopen.


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

Comment By: SourceForge Robot (sf-robot)
Date: 2006-08-14 04:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-07-30 13:16

Message:
Logged In: YES 
user_id=849994

Under 2.5, I get a runtime error now, so this might be fixed.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-08-05 21:22

Message:
Logged In: YES 
user_id=357491

Forgot to mention that Modules/threadmodule.c has 
thread_PyThread_start_new_thread which uses Python/
thread_*.h's PyThread_start_new_thread for executing threads;  
the '*' is replaced with the threading library used on your 
platform.  OS X should use thread_pthread.h (I think).

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

Comment By: Brett Cannon (bcannon)
Date: 2003-08-05 21:19

Message:
Logged In: YES 
user_id=357491

If you run ``str(Frog())`` instead of a bunch of threads you do get 
a RuntimeError.  Looks like this bus error has something to do 
with thread.start_new_thread and not 'str'.  It might be that since 
it runs using pthreads it does not have the built-in recursion limit 
check that the Python interpreter has.  Anyone with more 
experience with the 'thread' module have any ideas?

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

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