[Python-bugs-list] [ python-Bugs-480325 ] Tkinter crash on Win2000, OK on UNIX

[noreply@sourceforge.net]

Bugs item #480325, was opened at 2001-11-10 01:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480325&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: John W Lewis (lewisjwl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter crash on Win2000, OK on UNIX

Initial Comment:
Large Python/Tkinter application....
2GB virtual, 3600 images, 3600 graphic objects, 3600x3600 arrays
3200x1600 dual monitor graphics

Runs OK under 2.1.1 Python and Solaris8

Crashes in TK on Windows2000 at 3200 images
DELL 530 workstation with 4GB RAM
Windows 2000 SR1
2.1.1 Python

How do I go about isolating this problem?

Thanks
John Lewis



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

>Comment By: Martin v. Löwis (loewis)
Date: 2001-11-13 00:56

Message:
Logged In: YES 
user_id=21627

It helps to a degree, but only insofar as recognizing this
as a Tk problem. If you have the Tk source, you may want to
follow what I present as a theory:

In generic/tkImgPhoto.c:ImgPhotoInstanceSetSize, it invokes
Tk_GetPixmap. This is implemented in win/tkWinPixmap.c. If
CreateBitmap fails, it will return None, which is 0. 

So back in ImgPhotoInstanceSetSize, it will pass the null
pointer to TkSetPixmapColormap, which is again implemented
in tkWinPixmap.c, where it says

twdPtr->bitmap.colormap = colormap;

Since twdPtr comes from pixmap, which comes from newPixmap,
which may be null, this is a null-pointer access, which
causes the Access Violation.

Since this is the only action in TkSetPixmapColormap, and
since ImgPhotoInstanceSetSize is the only place where
TkSetPixmapColormap, this theory is quite likely, IMO, but
only single-stepping in a debugger may tell for sure.

In any case, it seems that CreateBitmap fails, which means
that you are running out of bitmap handles. To my knowledge,
on Win32, this only happens when you run out of memory; a
Windows expert may be able to give a more detailed analysis.

I see two problems:
- why doesn't Tk report the error properly? It doesn't
always check the return value, which it should; please
report that as a Tk bug: This is nothing we can do much
about; we won't go into the business of fixing Tk for ourselves.
- why does it run out of bitmap handles? This depends on
whether it is supposed to run out of bitmap handles: If it
is out of memory, there is not much you could do - it is an
application bug to allocate so many of them. 

If you are not out of memory, why does it fail to create
more bitmaps? That would be a Windows bug; please report it
to Microsoft :-) Perhaps MS has documented limitations on
creating too many bitmaps; if so, the ball is back on Tk's
side, which should use bitmap handles more conservatively,
or on the application's side, which should not create so
many bitmaps.

Perhaps this is something completely different; only a
debugger run could tell.

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

Comment By: John W Lewis (lewisjwl)
Date: 2001-11-12 09:27

Message:
Logged In: YES 
user_id=89001

>From the dump file....

Microsoft (R) WIndows 2000 (TM) Version 5.00 DrWtsn32

Application exception occured
App: (pid=1052)
Exception number: c0000005 (access violation)

Number of processors: 2
Processor Type x86 family 15 Model 0 Stepping 10
Windows 2000 VErsion: 5.0
Current Build 2195
Service Pack: 1
Current Type: Multiprocessor Free

!TkSetPixmapColormap
!Tk_CreatePhotoImageFormat
!Tk_CreatePhotoImageFormat
!Tk_CreatePhotoImageFormat
!Tk_GetImage
!Tk_InvokeButton
!Tk_InvokeButton
!Tk_CanvasObjCmd
!Tcl_EvalObjv
!Tcl_EvalObjv
!<nosymbols>

Is this helpful?
John

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-10 06:07

Message:
Logged In: YES 
user_id=21627

I recommend to attach to the process with a debugger (e.g.
VC++). If you manage to do this, please report the stack
trace at the moment of the crash.

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

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