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: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) 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-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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
