[ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED
SourceForge.net
noreply at sourceforge.net
Thu Feb 24 02:54:51 CET 2005
Bugs item #1121201, was opened at 2005-02-12 03:59
Message generated for change (Comment added) made by complex
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Neil Schemenauer (nascheme)
Summary: Python24.dll crashes, EXAMPLE ATTACHED
Initial Comment:
The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading).
Windows reports memory reference to 0x00000001 or 0xFFFFFFFF (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure.
I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray.
----------------------------------------------------------------------
>Comment By: Viktor Ferenczi (complex)
Date: 2005-02-24 02:54
Message:
Logged In: YES
user_id=142612
I'll use 2.3 until the next stable 2.4 release. I closed
this bug report - as requested.
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2005-02-24 01:41
Message:
Logged In: YES
user_id=35752
Complex,
You can increase the chances of sometone trying to debug
this by producing as small a test as possible. The attached
script (2D_Box.pyw) uses the 'scipy', 'psyco', and 'visual'
modules. Eliminating as many of them as possible will be a
big help.
As far as I can tell, bug #1120452 has nothing to do with
this bug. It's looks like a bug in the _sre module and it
appears that it has already been fixed in the CVS version of
Python.
----------------------------------------------------------------------
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-24 00:03
Message:
Logged In: YES
user_id=593130
In my opinion, reopening this, in the absence of additional
information that there really is a bug in Python itself, is an
inappropriate waste of developer time. Please reclose until such
time as you do have such evidence.
Please take any further discussion of the general stability of the
2.4 release to a more appropriate forum, such as
comp.lang.python, or the corresponding mailing list.
----------------------------------------------------------------------
Comment By: Viktor Ferenczi (complex)
Date: 2005-02-18 22:21
Message:
Logged In: YES
user_id=142612
In response to tim_one's message (2005-02-12 04:46):
I also like python and use it for several hours a day. Python 2.3.4 and 2.3.5 are very stable and I couldn't crash them (without buggy extension modules). I claim only that 2.4.0 is unstable at least in some use cases.
Please see bug #1120452, for example:
http://sourceforge.net/tracker/?func=detail&aid=1121201&group_id=5470&atid=105470
The attached app uses only pure python and standard library for simple HTML templating. Note, that PyMeld does not use a C extension. It can crash Python 2.4.0 with a segfault under Windows XP and Debian Linux 3.0r2 (kernel 2.4.28). The bug has been reproduces by another sourceforge users.
Thanks for your comment.
Greetings, Complex
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2005-02-18 22:21
Message:
Logged In: YES
user_id=357491
Since this seems to be a VPython issue closing as invalid.
----------------------------------------------------------------------
Comment By: Viktor Ferenczi (complex)
Date: 2005-02-18 21:53
Message:
Logged In: YES
user_id=142612
Thanks for the info. I'm waiting for a stable version of VPython.
----------------------------------------------------------------------
Comment By: logistix (logistix)
Date: 2005-02-17 02:53
Message:
Logged In: YES
user_id=699438
Also note that :
http://vpython.org/win_download24.html
has the following text ;-)
"""
This version of VPython for Python 2.4 should be considered
experimental. Known bugs: 1) Programs that use the "text"
module to display block letters (including the demo programs
stonehenge.py and texttest.py) fail on some computers. We
would appreciate feedback on any bugs you may find.
"""
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2005-02-12 04:46
Message:
Logged In: YES
user_id=31435
You should report this to the Visual Python developers;
historically, invalid memory references are usually due to bugs
in non-core C extension modules. This is especially true here
since your last report is of a crash inside cvisual.dll -- it's
unlikely that anyone working on core Python can help you
with that.
BTW, yours is the first claim I've heard that Python 2.4
is "very unstable", and no bugfixes in 2.4.1 yet are anything
I'd consider to be major -- major bugs just haven't been
reported. I use Python 2.4 myself on Windows, for hours
every day, mostly as part of Zope/ZODB development. No
problems there either.
----------------------------------------------------------------------
Comment By: Viktor Ferenczi (complex)
Date: 2005-02-12 04:30
Message:
Logged In: YES
user_id=142612
I've changed the main loop again to exlude most of the numarray computations:
while 1:
vi.rate(20)
# Draw state
#Display(WF*conjugate(WF)).real*scale)
Display(identity(resolution[0]))
# Time step
#TimeStep()
t+=step
After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables.
After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere.
I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released.
Please inform me if you need any assistance to narrow down this bug further.
Note: I've not tried this on Linux or non-HT CPU, but I will do.
Thanks for any help.
----------------------------------------------------------------------
Comment By: Viktor Ferenczi (complex)
Date: 2005-02-12 04:19
Message:
Logged In: YES
user_id=142612
I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?).
I've changed the main loop of the attached example to:
while 1:
vi.rate(20)
# Draw state
#Display(WF*conjugate(WF)).real*scale)
Display(identity(resolution[0]))
# Time step
TimeStep()
t+=step
After 10-20 seconds of operation the following appears (don't ask, my machine is stable):
Visual 2005-01-08
Traceback (most recent call last):
File "2D_Box.pyw", line 141, in ?
Display(identity(resolution[0]))
File "2D_Box.pyw", line 125, in Display
seg[y][x+1].pos[3][2]=p
TypeError: unsubscriptable object
The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470
More information about the Python-bugs-list
mailing list