Python has crashed twice over the last week on one of my clients machine, but I can’t reproduce it on my machine. The only information I have is the following:
Faulting application pythonw.exe, version 0.0.0.0, faulting module wxmsw28uh_adv_vc.dll, version 2.8.12.1, fault address 0x00019787
That offending DLL is a wxWidgets DLL, hence the reason I’m posting to this group.
I was hoping to get more information by analyzing a crash dump (from userdump.exe) in Visual Studio’s debugger, but for that to be successful I need a debug version of wxPython (wxWidgets) with the windows PDB files. Is there somewhere I can download such a beast (Windows XP, wxPython 2.8.12.1, Python 2.7.2)? I was hoping this might be easier than having to build wxPython myself. (If there is another approach I can take to track down this fault, please enlighten me).
Python has crashed twice over the last week on one of my clients
machine, but I can't reproduce it on my machine. The only information I
have is the following:
Faulting application pythonw.exe, version 0.0.0.0, faulting module
wxmsw28uh_adv_vc.dll, version 2.8.12.1, fault address 0x00019787
That offending DLL is a wxWidgets DLL, hence the reason I'm posting to
this group.
I was hoping to get more information by analyzing a crash dump (from
userdump.exe) in Visual Studio's debugger, but for that to be successful
I need a debug version of wxPython (wxWidgets) with the windows PDB
files. Is there somewhere I can download such a beast (Windows XP,
wxPython 2.8.12.1, Python 2.7.2)?
No, the Windows -devel package only includes the release mode libs and DLLs.
I was hoping this might be easier than
having to build wxPython myself. (If there is another approach I can
take to track down this fault, please enlighten me).
If you can reproduce the problem in a small self-contained runnable sample then I can take a look at that while running in the debugger.
in pythonw.exe: 0xC0000005: Access violation writing location
0x05e13754.
stackframe: wxmsw28uh_adv_vc.dll!00e99787()
I believe there was some mention of _grid.dll also.
Unfortunately, it is essentially impossible to debug anything from
this, because the DLL has been relocated. wxmsw28uh_adv_vc.dll
loads, by default, at 10000000. Without knowing what its actual
load address was for you, we can’t tell where in the DLL this
actually occurred.
What operating system is this? The error dialog should tell you a
location where it has stored more information about the crash.
There may also be more information in the event log.
The OS is Windows XP. I had a look in the Event Viewer but could not find any reference to the error. Strange. Maybe it’s because the Visual Studio debugger kicked in; that is where the error message in my last post came from. If my application crashes again on a machine where Visual Studio is installed, is there any useful information I can get from Visual Studio that may help (other than the load address you already mentioned)? Sadly, the crash usually occurs on an end-user machine, without Visual Studio, and only rarely (at least they report it rarely!!).
The OS is Windows XP. I had a look in the Event Viewer but could not
find any reference to the error. Strange. Maybe it's because the
Visual Studio debugger kicked in; that is where the error message in
my last post came from. If my application crashes again on a machine
where Visual Studio is installed, is there any useful information I
can get from Visual Studio that may help (other than the load address
you already mentioned)?
In Visual Studio, you can do Debug -> Save Dump As to save a "minidump
with heap". Put it somewhere save and send the link to the list. That
would be a great start.
That's not in the Express Editions, however.
···
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
If the application is using the Grid class then take a look at any grid attributes, editors or renderers that are used and check if they need to have IncRef called. A common issue with these items is that their internal reference count is getting decremented to zero and they are being destroyed, but are still being used someplace.
···
On 11/15/11 5:25 AM, Const wrote:
Python crashed again yesterday. Here's the only information I have:
Unhandled exception at 0x00e99787 in pythonw.exe: 0xC0000005: Access
violation writing location 0x05e13754.
stackframe: wxmsw28uh_adv_vc.dll!00e99787()
I believe there was some mention of _grid.dll also.
The three crashes seem random, i.e. the client was doing different
things each time a crash was reported.
So far I can't reproduce the problem in a small self-contained runnable
sample.
Under what circumstances does one need to call IncRef()/DecRef? E.g., should IncRef() be called if I’m sharing the same GridCellAttr instance between many columns?
attr = GridCellAttr() # increments ref to 1
self.SetRowAttr(0, attr)
attr.IncRef() # increments ref to 2
self.SetRowAttr(1, attr)
Please correct me if I’m wrong.
I was completely unaware of this IncRef/DecRef issue; I just assumed Python/wxPython would handle such details automatically. Now I know (due to some technical reasons), this is not the case. Thanks for your help. I hope this fixes my crashing problem. I will keep the group posted.