Take a look in the Event log->application view, it may provide some extra information. You could configure DrWatson to produce a crash dump, if you have the will to try and understand such.
Otherwise, it's a case of commenting stuff out until it stops crashing, then putting it back a piece at a time until it does it again. That should localise the problem enough that you can what your doign wrong.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
| [reply] |
Since you seem to have isolated the problem to the point where the script is "loading items into the Treeview", the next step might be to try one of the following:
- use the debugger to step into the Treeview loading process, to see if there is a specific point where the fault occurs (this could be quite tedious, depending on the amount of data being loaded, and where the problem happens in the data set)
- try using different amounts and types of input data -- and take some other form of dump from the MLDBM file, to check its contents for unexpected "features".
It might be easiest to try varying the input data first, to see whether it crashes under all conditions (in which case, present a simple demo of the problem to the module author).
If it works for some data sets and not others, the issue is either the quantity or the quality of the data. Let's suppose it's crashing on data set "X"; try to divide that set into two or more pieces of fairly equal size, such that it runs okay with just the first piece, then run it on the other pieces to see if those work as well. If it crashes on any of those other pieces, you know where to look for a data quality problem; otherwise, it's a limitation on quantity (in which case, the module author might want to know). | [reply] |
I can't say I know very much about the particular module you're using. However, it seems to me that you should use strategically placed print statements (or some other output) to determine where the program dies so that you can single out the exact statement or statements where the program dies and whatever parameters are being used at that point. (Pretty much standard debugging procedure.) This way you don't have to rely on a debugger and OS error messages.
Once you do so (or if you've already done so), by providing the problem code and input, fellow monks may be more able to help you.
Zenon Zabinski | zdog | zdog@perlmonk.org
| [reply] |
I recall something similar when developing Perl Oasis many moons ago. It's kind of vague now...
..oO(I think it had something to do with a node getting focus or something)
What Win32::GUI version do you use? If it's that old 0.0.558 version, you should consider upgrading ASAP.
If not, maybe you can try to reproduce a minimal example and post it to the win32-gui-users mailing list.
/J
| [reply] |