Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I wrote a program using Win32::GUI, Win32::OLE, and Math::Interpolate to import data from text files, do some comparissons and operations on the data, and then place the data in an Excel workbook.

Some Info:
Each text file contains 1 header, and ~80 - 160 integers seperated by line. Each text file is converted to it's own worksheet in the work book. And each worksheet contains a graph. The total number of files that I am importing data from ~215.

The Problem:
It works....BUT ~80% of the time I get a
"The instruction at 0x######## referenced memory at 0x0000000(0-8). The memory could not be "read"/"written"."
I have noticed that the referenced memory ranges from 0x00000000 to 0x00000008.

Some Diagnostics:
I have added lines within the program to print numbers to a log file so that I see where in the program it would fail, but the log only proved that the location of failure was random.
I originally wrote the program using global variables and undef'ing when necesary (bad programming..I know) I have since gone back and changed everything to local variables to allow PERL to handle the memory and the percent of time that I receive the error is now ~70%.
I tried using ptkdb to debug the program and I noticed that when using it the error occured ~15-20% of the time.

More Info:
To keep things organized I put the code in individual files and use "require" to access it. I would post the code, but it is long, complex and extends over 2 files.
I use "use strict, use warnings, and use diagnostics" and the only warnings that I get are "use of uninitialized values in subroutine, and these only occure for Win32::GUI calls (i.e. Win32::GUI::Dialog()).
I am using perl 5.8.3 on a Win2k box. I get similar errors on other OS's running a perl2exe version, but I do not know that that is a very telling test.


Any help on this issue is most appreciated, I have spent a week already trying to track it down.

Thanks in advance,

Cameron
  • Comment on Problems with Win32::OLE and Excel specifically memory could not read/written.

Replies are listed 'Best First'.
Re: Problems with Win32::OLE and Excel specifically memory could not read/written.
by PodMaster (Abbot) on Feb 25, 2004 at 14:45 UTC
    Have you tried using Devel::Trace (as in `perl -d:Trace program ...')?

    Do you have a real debugger (like one that comes with microsoft visual studio)? Try compiling perl with debugging on, and then fireing up the debugger when you get the memory access violation error (usually happens when you hit "Cancel to start the debugger"). That should tell you exactly where the error is occuring, so you can backtrack from there.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      I had not tried Devel::Trace, running that now I have found that in the last 3 times running/crashing it stopped at 3 different places in the code. The last on stopped at:
      @contents = @$contentsref;

      nothing wrong with that line, or any of the others that I have seen....

      Yes I have VS Debug....running it by hitting 'cancel' gives me:
      "Unhandled exception in perl.exe (NTDLL.DLL): 0xC0000005: Access Violation."

      Further inspection shows:
      NTDLL! 77fcb3af()    ->  77FCB3AF   mov         dword ptr eax+4,ecx
      NTDLL! 77fcc8d7()    ->  77FCC8D7   mov         esi,eax
      MSVCRT! 78001e00()   ->  78001E00   mov         ecx,dword ptr ebp-10h
      PERL58! 280869f9()   ->  280869F9   mov         eax,dword ptr edi
      PERL58! 28066179()   ->  28066179   cmp         dword ptr esi+4,0
      PERL58! 28024dd7()   ->  28024DD7   add         esp,0Ch
      GUI!01d90ec7()       ->  01D90EC7   add         esp,4
      USER32! 77e3a2d0()   ->  77E3A2D0   cmp         dword ptr esp+4,0DCBAABCDh
      USER32! 77e16362()   ->  77E16362   mov         ecx,eax
      USER32! 77e17341()   ->  77E17341   jmp         77E17389
      USER32! 77e308f5()   ->  77E308F5   ret         8
      USER32! 77e2e00c()   ->  77E2E00C   jmp         77E2E01D
      USER32! 77e3a2d0()   ->  77E3A2D0   cmp         dword ptr esp+4,0DCBAABCDh
      USER32! 77e145e5()   ->  77E145E5   mov         ecx,eax
      USER32! 77e15b51()   ->  77E15B51   ret         4
      PERL58! 28040681()   ->  28040681   cmp         dword ptr ebp-10h,0
      PERL58! 2805eda5()   ->  2805EDA5   test         eax,eax
      PERL58! 28089764()   ->  28089764   pop         ecx
      PERL! 00401012()     ->  00401012   add         esp,0Ch
      KERNEL32! 7c5987e7() ->  7C5987E7   push         eax


      I hope this means something to someone out there, cause my assembly knowledge is next to none.
      The above code was taken from "context" in the debugger.

      As far as file numbers being a factor...yes definately I know that the more files that I am converting the greater the chance of seeing this error....I think that it is statistical and not the cause. I have seen it fault @ 5% completion and at 75% completion, so the problem does occur at different file numbers.

      I hope that this info can shed some light on this...if anyone else has any suggestions or needs any other info just say it...I will try nearly anything :)


      Thanks again,

      Cameron

        Find which files it is faulting on. Analyze those files for any trends in the data. Perhaps certain data causes the violation in conjuction with your algorithm. Is it dying on files with extremely large numbers? Posting your full code will help give a better picture of what is going on. Perhaps it doesn't stop on the line that is at fault, but rather once perl has caught up with itself, it stops at whatever line it happens to be parsing at the time?

        Thinking aloud really.. some of the above is probably total bs. Just trying to foster ideas to help you with this.

        Grygonos
Re: Problems with Win32::OLE and Excel specifically memory could not read/written.
by Grygonos (Chaplain) on Feb 25, 2004 at 15:56 UTC

    There could be an issue with creating a large number of sheets in a workbook in Excel. Have you tried running it on a smaller quantity of files? I would try that and (depending on how long it takes to run this script) get a good statistical sampling of crashes at certain file quantities and see where the problem starts to occur... this will reveal if it is a quantity issue or a random issue.

    Just a thought,

    Grygonos
Re: Problems with Win32::OLE and Excel specifically memory could not read/written.
by Anonymous Monk on Feb 26, 2004 at 13:26 UTC
    OK, here is the code:
    Code


    Sorry if it is messy and not well documented.


    Cameron