Just plain weird behavior from Epic

2010-10-26
2013-05-20
  • Rob Johansen

    Rob Johansen - 2010-10-26

    Hi all,

    Here's my setup:

    - Windows XP SP3
    - ActivePerl 5.10.0 build 1004 built for MSWin32-x86-multi-thread
    - Eclipse 3.6.1
    - Epic 0.5.46

    I'm seeing some extremely unpredictable and buggy behavior from Epic. I've got a very simple Win32::GUI project that displays a window with a few labels and a couple buttons-something I've done a hundred times before in other projects without any problems. However, just today, when I attempt to run one specific project in Epic (Ctrl + F11), perl.exe crashes with the glorious and useless error:

    The instruction at "0x7c928c0b" referenced memory at "0x00080700". The memory could not be "read".

    Once this occurs I can reproduce the problem in Epic at will-every time I run the project, the crash occurs. Here's what's so odd:

    1. If I go out to the file system and execute the perl script from a command prompt, it runs without any problems whatsoever.

    2. After running the script from a command prompt, I can go back to Epic and run the project from Epic one time successfully. Thereafter, the project will no longer run in Epic and I'm back to the crashing (until I run the script from a command prompt again).

    3. Sometimes making an insignificant change to the code, like adding a new line or removing a blank line, allows me to run the project one time in Epic.

    4. None of my other Win32::GUI projects exhibit this weird behavior.

    What could be different between the way Epic executes the project and the way I'm executing the project from a command prompt? Is this a known bug or has anyone else seen it? Does anyone have ideas for troubleshooting this strange and annoying problem?

     
  • Jan Ploski

    Jan Ploski - 2010-10-27

    It would be helpful if you could reproduce the crashing behavior outside of EPIC. You can observe the full command line that EPIC uses to launch perl.exe through the 'Error Log' (either a view labeled so, or the file workspace/.metadata/.log) after you enable 'Debugger console (experimental)' in EPIC preferences. Another factor that may be contributing are the values of environment variables (which may be different when running Perl from EPIC than from the command line) and the current working directory. Finally, there is the lack-of-terminal-emulation difference (when EPIC runs a Perl script, it does it as if you redirected STDIN/STDOUT/STDERR to a different process; when you run it from command-line, Perl knows that it has a "terminal" available).

    Check with task manager that after the crash no perl.exe processes are left hanging around.

    Also consider the possibility that the observed "causality" between your actions and the crashing/non-crashing may be spurious. For example, it might simply be time passing that prevents the crash, not your manipulations.

    You could also slice and dice your crashing project until it stops crashing to find a contributing factor within it (since you say no other project is crashing, this makes the case a candidate for delta debugging).

    I suppose that you are not running under debugger in EPIC. If so, there is a whole new set of factors to consider. I recall Win32 libraries behaving differently when run under debugger than otherwise.

     
  • Oliver Trosien

    Oliver Trosien - 2011-02-01

    Have you tried using the most recent EPIC version from the testing tree?

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks