#386 CGI,no breakpoints,100% cpu perl.exe zombies,ignore use lib,

v0.6.x
closed-fixed
Debugger (177)
5
2007-05-27
2007-04-21
Anonymous
No

Moving from eclipse 3.1.2 to 3.2.2
(Build id: M20070212-1330) and from
EPIC 0.3.12 to EPIC 0.6.0
(NOTE:Debugging worked in this previous setup)

Using same perl as before:
activestate perl 5.8.7
1. PadWalker [0.10] PadWalker - from EPIC site as I recall.

Trying to do CGI debugging with external browser.

Noticed that editor seems to be much improved ;), finds my subroutines etc.

But with debugging many problems (so many I wonder if I have just missed some crucial step):
0. often failed to "could not connect to debug port" errors - usually a sign that a rogue perl.exe is still
running somewhere from a prior run - using lots of RAM and CPU. Kill. Then OK.
1. occasional Exception processing Debug Async Queue
2. more critically - breakpoints are completely ignored
(similar to 1672279?)
3. does stop at first statement - (global setting)
4. but stepping down into code often freezes and icons to step in/over etc. are no longer illuminated.
5. use lib 'lib'; (which works in old setup!) for pm files;files are "found" but not displayed,
in debugger (you only get an increasing line number as you step...)
----------------------
!MESSAGE An unexpected exception occurred while creating a link to lib/SomeModule.pm
!STACK 1
org.eclipse.core.internal.resources.ResourceException: lib is not a valid location. The location is relative to undefined workspace path variable "lib".
at org.eclipse.core.internal.resources.Resource.assertLinkRequirements(Resource.java:154)
at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:588)
at org.eclipse.core.internal.resources.Resource.createLink(Resource.java:570)
at org.epic.core.util.FileUtilities.createFolderLink(FileUtilities.java:90)
at org.epic.core.util.FileUtilities.getFileEditorInput(FileUtilities.java:27)
at org.epic.debug.ui.DebugModelPresentation.getEditorInput(DebugModelPresentation.java:167)
at org.eclipse.debug.internal.ui.LazyModelPresentation.getEditorInput(LazyModelPresentation.java:212)
at org.eclipse.debug.internal.ui.sourcelookup.SourceLookupFacility.lookup(SourceLookupFacility.java:174)
at org.eclipse.debug.ui.DebugUITools.lookupSource(DebugUITools.java:689)
at org.eclipse.debug.internal.ui.elements.adapters.StackFrameSourceDisplayAdapter$SourceLookupJob.run(StackFrameSourceDisplayAdapter.java:101)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SUBENTRY 1 org.eclipse.core.resources 2 333 2007-04-21 16:51:30.062
!MESSAGE lib is not a valid location. The location is relative to undefined workspace path variable "lib".
!SUBENTRY 1 org.eclipse.core.resources 2 333 2007-04-21 16:51:30.062
!MESSAGE lib is not a valid location. The location is relative to undefined workspace path variable "lib".
----------------------
Even though I now get the files displayed if I step into the modules, breakpoints
are still ignored.

Discussion

  • Nobody/Anonymous

    Logged In: NO

    Forgot to add, this is on Windows XP Home SP2

     
  • mke

    mke - 2007-04-21

    Logged In: YES
    user_id=1775262
    Originator: NO

    This part should have read:
    Workaround is to explicitly set the path:

    use lib 'D:\XXX\workspace3.2\ProjectName\cgi\lib';

    Even though I now get the files displayed if I step into the modules,
    breakpoints are still ignored.

     
  • Jan Ploski

    Jan Ploski - 2007-04-22

    Logged In: YES
    user_id=86907
    Originator: NO

    0: This is most probably a consequence of problem #1 and/or #4.
    1: Right, you should post an exception stack trace for this one as well. I encountered a similar problem a few times today under Linux, but it is hard to reproduce. I released some changes in 0.5.34 which *might* correct this problem. I suggest you switch to 0.5.34 (stable) to help evaluate these changes.
    2: The ignored breakpoints phenomenon is indeed very likely as reported in 1672279. You can read that bug report to understand why this happens, why I don't see a way to fix it and what you can possibly do about it yourself.
    3: Well, at least one thing that works ;)
    4: This is something which got reported before, but I have never experienced it under Linux. There is some hope that the changes in 0.5.34 affect it as well. Also, I hope to work under Windows some time soon and perhaps I can reproduce it there.
    5: Do you really *need* the "use lib" thing in your code? I recommend that you set up your project to
    - rely on the @INC path configured in project properties when programming/debugging in EPIC
    - in production environment, set the @INC path from outside of your scripts - either by letting the web server run the Perl interpreter with appropriate -I option(s) or by setting the environment variable PERLLIB prior to running the interpreter

     
  • mke

    mke - 2007-04-23

    Logged In: YES
    user_id=1775262
    Originator: NO

    Move to 0.5.34.
    I am a bit confused. I thought the testing feed was 0.6.x for 3.2.2 eclipse?
    as recommended on the web site. Is there a 0.6.x update/testing version or
    should I now use http://e-p-i-c.sf.net/updates?

    Your point number 1:
    -----
    Here's the stack for #1:

    !ENTRY org.eclipse.debug.core 4 120 2007-04-21 17:43:53.968
    !MESSAGE Exception processing debug async queue
    !SUBENTRY 1 org.eclipse.debug.core 4 120 2007-04-21 17:43:53.968
    !MESSAGE Exception processing debug async queue
    !STACK 0
    java.lang.NullPointerException
    at org.epic.debug.util.RemotePort.waitForConnect(RemotePort.java:163)
    at org.epic.debug.util.RemotePort.waitForConnect(RemotePort.java:158)
    at org.epic.debug.cgi.CGIDebugTarget.acceptNewDebugger(CGIDebugTarget.java:81)
    at org.epic.debug.cgi.CGIDebugTarget.access$1(CGIDebugTarget.java:77)
    at org.epic.debug.cgi.CGIDebugTarget$2.run(CGIDebugTarget.java:73)
    at org.eclipse.debug.core.DebugPlugin$AsynchJob.run(DebugPlugin.java:1022)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

    !ENTRY org.eclipse.update.configurator 2007-04-21 17:52:23.265
    !MESSAGE Can't find bundle for base name feature, locale de_DE

    I did try some settings for @INC in the project properties without success. Will try some more (based e.g. on what I read in 1672279) and get back to you.

     
  • mke

    mke - 2007-04-23

    Logged In: YES
    user_id=1775262
    Originator: NO

    Follow up.
    The debug async queue message occurs when I try to set a breakpoint:
    Here's a recent stack:
    !ENTRY org.epic.debug 4 0 2007-04-23 16:01:06.171
    !MESSAGE Debug Error
    !STACK 1
    org.eclipse.debug.core.DebugException: An error occurred during communication with the debugger process
    at org.epic.debug.db.PerlDB.throwDebugException(PerlDB.java:639)
    at org.epic.debug.db.PerlDB.addBreakpoint(PerlDB.java:125)
    at org.epic.debug.db.PerlDB.addBreakpoint(PerlDB.java:111)
    at org.epic.debug.PerlBreakpointManager.breakpointAdded(PerlBreakpointManager.java:73)
    at org.eclipse.debug.internal.core.BreakpointManager$BreakpointNotifier.run(BreakpointManager.java:795)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.debug.internal.core.BreakpointManager$BreakpointNotifier.notify(BreakpointManager.java:821)
    at org.eclipse.debug.internal.core.BreakpointManager.fireUpdate(BreakpointManager.java:735)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoints(BreakpointManager.java:487)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoints(BreakpointManager.java:437)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoint(BreakpointManager.java:430)
    at org.epic.debug.PerlLineBreakpoint.register(PerlLineBreakpoint.java:114)
    at org.epic.debug.PerlLineBreakpoint$1.run(PerlLineBreakpoint.java:85)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
    at org.epic.debug.PerlLineBreakpoint.run(PerlLineBreakpoint.java:129)
    at org.epic.debug.PerlLineBreakpoint.createPerlLineBreakpoint(PerlLineBreakpoint.java:89)
    at org.epic.debug.PerlLineBreakpoint.<init>(PerlLineBreakpoint.java:51)
    at org.epic.debug.PerlLineBreakpoint.<init>(PerlLineBreakpoint.java:43)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter.createLineBreakpoint(ToggleBreakpointAdapter.java:203)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter.access$1(ToggleBreakpointAdapter.java:174)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter$1.run(ToggleBreakpointAdapter.java:118)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
    org.eclipse.debug.core.DebugException[0]: java.io.IOException: Stream closed
    at java.io.BufferedReader.ensureOpen(BufferedReader.java:97)
    at java.io.BufferedReader.read(BufferedReader.java:253)
    at java.io.Reader.read(Reader.java:100)
    at org.epic.debug.db.DebuggerInterface.readCommandOutput(DebuggerInterface.java:404)
    at org.epic.debug.db.DebuggerInterface.runCommand(DebuggerInterface.java:352)
    at org.epic.debug.db.DebuggerInterface.access$2(DebuggerInterface.java:320)
    at org.epic.debug.db.DebuggerInterface$Command.run(DebuggerInterface.java:509)
    at org.epic.debug.db.DebuggerInterface.commandLoop(DebuggerInterface.java:94)
    at org.epic.debug.db.DebuggerInterface.access$3(DebuggerInterface.java:83)
    at org.epic.debug.db.DebuggerInterface$2.run(DebuggerInterface.java:60)
    at java.lang.Thread.run(Thread.java:534)
    !SUBENTRY 1 org.epic.debug 4 0 2007-04-23 16:01:06.218
    !MESSAGE An error occurred during communication with the debugger process
    !STACK 0
    java.io.IOException: Stream closed
    at java.io.BufferedReader.ensureOpen(BufferedReader.java:97)
    at java.io.BufferedReader.read(BufferedReader.java:253)
    at java.io.Reader.read(Reader.java:100)
    at org.epic.debug.db.DebuggerInterface.readCommandOutput(DebuggerInterface.java:404)
    at org.epic.debug.db.DebuggerInterface.runCommand(DebuggerInterface.java:352)
    at org.epic.debug.db.DebuggerInterface.access$2(DebuggerInterface.java:320)
    at org.epic.debug.db.DebuggerInterface$Command.run(DebuggerInterface.java:509)
    at org.epic.debug.db.DebuggerInterface.commandLoop(DebuggerInterface.java:94)
    at org.epic.debug.db.DebuggerInterface.access$3(DebuggerInterface.java:83)
    at org.epic.debug.db.DebuggerInterface$2.run(DebuggerInterface.java:60)
    at java.lang.Thread.run(Thread.java:534)

    !ENTRY org.eclipse.debug.core 4 120 2007-04-23 16:01:06.484
    !MESSAGE Exception processing debug async queue
    !SUBENTRY 1 org.eclipse.debug.core 4 120 2007-04-23 16:01:06.484
    !MESSAGE Exception processing debug async queue
    !STACK 0
    java.lang.NullPointerException
    at org.epic.debug.util.RemotePort.waitForConnect(RemotePort.java:163)
    at org.epic.debug.util.RemotePort.waitForConnect(RemotePort.java:158)
    at org.epic.debug.cgi.CGIDebugTarget.acceptNewDebugger(CGIDebugTarget.java:81)
    at org.epic.debug.cgi.CGIDebugTarget.access$1(CGIDebugTarget.java:77)
    at org.epic.debug.cgi.CGIDebugTarget$2.run(CGIDebugTarget.java:73)
    at org.eclipse.debug.core.DebugPlugin$AsynchJob.run(DebugPlugin.java:1022)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

    !ENTRY org.eclipse.debug.core 4 2 2007-04-23 16:01:06.906
    !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.debug.core".
    !STACK 0
    java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
    at java.util.HashMap$KeyIterator.next(HashMap.java:818)
    at org.epic.debug.PerlBreakpointManager.breakpointAdded(PerlBreakpointManager.java:70)
    at org.eclipse.debug.internal.core.BreakpointManager$BreakpointNotifier.run(BreakpointManager.java:795)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.debug.internal.core.BreakpointManager$BreakpointNotifier.notify(BreakpointManager.java:821)
    at org.eclipse.debug.internal.core.BreakpointManager.fireUpdate(BreakpointManager.java:735)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoints(BreakpointManager.java:487)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoints(BreakpointManager.java:437)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoint(BreakpointManager.java:430)
    at org.epic.debug.PerlLineBreakpoint.register(PerlLineBreakpoint.java:114)
    at org.epic.debug.PerlLineBreakpoint$1.run(PerlLineBreakpoint.java:85)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
    at org.epic.debug.PerlLineBreakpoint.run(PerlLineBreakpoint.java:129)
    at org.epic.debug.PerlLineBreakpoint.createPerlLineBreakpoint(PerlLineBreakpoint.java:89)
    at org.epic.debug.PerlLineBreakpoint.<init>(PerlLineBreakpoint.java:51)
    at org.epic.debug.PerlLineBreakpoint.<init>(PerlLineBreakpoint.java:43)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter.createLineBreakpoint(ToggleBreakpointAdapter.java:203)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter.access$1(ToggleBreakpointAdapter.java:174)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter$1.run(ToggleBreakpointAdapter.java:118)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

    !ENTRY org.eclipse.debug.core 4 120 2007-04-23 16:01:06.906
    !MESSAGE An exception occurred during breakpoint change notification.
    !STACK 0
    java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
    at java.util.HashMap$KeyIterator.next(HashMap.java:818)
    at org.epic.debug.PerlBreakpointManager.breakpointAdded(PerlBreakpointManager.java:70)
    at org.eclipse.debug.internal.core.BreakpointManager$BreakpointNotifier.run(BreakpointManager.java:795)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.debug.internal.core.BreakpointManager$BreakpointNotifier.notify(BreakpointManager.java:821)
    at org.eclipse.debug.internal.core.BreakpointManager.fireUpdate(BreakpointManager.java:735)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoints(BreakpointManager.java:487)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoints(BreakpointManager.java:437)
    at org.eclipse.debug.internal.core.BreakpointManager.addBreakpoint(BreakpointManager.java:430)
    at org.epic.debug.PerlLineBreakpoint.register(PerlLineBreakpoint.java:114)
    at org.epic.debug.PerlLineBreakpoint$1.run(PerlLineBreakpoint.java:85)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
    at org.epic.debug.PerlLineBreakpoint.run(PerlLineBreakpoint.java:129)
    at org.epic.debug.PerlLineBreakpoint.createPerlLineBreakpoint(PerlLineBreakpoint.java:89)
    at org.epic.debug.PerlLineBreakpoint.<init>(PerlLineBreakpoint.java:51)
    at org.epic.debug.PerlLineBreakpoint.<init>(PerlLineBreakpoint.java:43)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter.createLineBreakpoint(ToggleBreakpointAdapter.java:203)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter.access$1(ToggleBreakpointAdapter.java:174)
    at org.epic.debug.ui.action.ToggleBreakpointAdapter$1.run(ToggleBreakpointAdapter.java:118)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

     
  • Jan Ploski

    Jan Ploski - 2007-04-23

    Logged In: YES
    user_id=86907
    Originator: NO

    > I am a bit confused. I thought the testing feed was 0.6.x for 3.2.2 eclipse?

    That's correct. 0.6.x (testing) works with Eclipse >=3.2 only, 0.5.x (stable) works with both 3.1 and 3.2.

    > Is there a 0.6.x update/testing version or should I now use http://e-p-i-c.sf.net/updates?

    I recommend that you switch to 0.5.34 (hence use http://e-p-i-c.sf.net/updates\) temporarily to work around your current problems. I did a few tests under Windows today and managed to break 0.5.33 easily by repeatedly clicking on the Step buttons. 0.5.34 withstood the same tests (while still being exruciatingly slow).

    The upcoming 0.6.1 will include significant changes to the debugger to improve performance, but it is still a few weeks away. So stay with 0.5.x (x >= 34) for now and then switch back to 'testing' when 0.6.1 is released.

     
  • mke

    mke - 2007-04-26

    Logged In: YES
    user_id=1775262
    Originator: NO

    Status:
    eclipse 3.2.2 and 0.5.34 instead of 0.6.0
    "Perl Include Path" in "Project properties" set to absolute paths for cgi and cgi/lib directory
    Windows XP Home SP2 etc.
    Debug file types set to .pl,.pm etc.

    Major problems are that the debugging dies or that step overs become resumes.
    A constant eye must be kept on perl.exe, to kill it before system degradation.

    The behaviour is erratic, each run produces a different result
    at various depths.
    The following is an attempt to represent what happens:

    1. stop of first line works ;)
    2. breakpoints work, also in .pm files in "lib" directory
    2.1 files are now correctly displayed as i step through ;)
    3. note: use lib statements must be removed or commented out! duh
    4. info: programming uses perl "objects"
    5. stepping from "main".pl into xxx.pm, both are displayed (kind of stack) under Main Thread...
    6. stepping from xxx.pm into yyy.pm, stack is cleared and only yyy.pm appears(?) under "Main Thread" - "object" to "object"
    - shouldn't complete "call stack" still appear? (maybe a feature)
    7. breakpoints here still work
    8. erratic behaviour at this stage - e.g. step over or resume etc. does not return
    8.1 sometimes perl.exe starts to hog cpu and ram, sometimes perl.exe runs but does not hog
    8.2 only option highlighted for thread in debugger is the red terminate square, does usually kill perl.exe
    9 sometimes end up in perl system .pm files without stepping in, e.g. after clicking resume or step over etc.
    - these often appear to be debug related perl modules
    9.1 sometimes get the source code OR sometimes the message File /epic_links/<some number>/Symbol.pm does not exist
    10 sometimes in object x, i step on to a statement and then can no longer step over. Only step out or
    step in are offered despite code for step over being present.
    Step out has effect of a resume at this point - instead of unwinding scope,
    it stops at the next breakpoint
    11 generally, sometimes step over acts like resume, effect appears to be random(?), makes debugging difficult
    12 file being stepped through is displayed - always in "same tab" - probably a feature

     
  • Jan Ploski

    Jan Ploski - 2007-04-26

    Logged In: YES
    user_id=86907
    Originator: NO

    I decided to speed up release of 0.6.1 by leaving out the highlighting of changes feature in the Variables view, so it's out today. Switch back to the 'testing' version of EPIC.

    Concerning your observations:
    6: The complete stack should appear. This was another Windows-specific bug, fixed in 0.5.35 and 0.6.1
    8: It may be a good idea to upgrade to the current version of ActiveState Perl. The "perl hogs cpu" problems may very well be caused by bugs in 5.8.7. I'd be also interested if you can reproduce it in 0.6.1. If you can reproduce it, you should submit contents of the "debug console", which logs communication between EPIC and the Perl debugger. You can enable the debug console in EPIC preferences.
    9: Step over _is_ stepping and it sometimes exhibits strange behavior even in the Perl's own debugger. When this is the case, EPIC can do nothing about it, as it works with the Perl debugger behind the scenes and obtains file/line info from it directly.
    9.1: No idea, possibly an unrelated bug.
    10, 11: You should be more precise. Try reaching the same line using Perl's own debugger and see where "step out" takes you. I suspect they may belong to the same category as #8. If this is a problem with perl -d, then the effect should be definitely reproducible (both in perl -d and in EPIC), and not "random". It's hard to tell what you mean by that.
    12: Yes, this is a feature.

     
  • mke

    mke - 2007-04-27

    Logged In: YES
    user_id=1775262
    Originator: NO

    I moved to 0.6.1 and perl 5.8.8.821 from 5.8.7.817
    installed padwalker 0.10 via the PPM gui.
    Now I get the padwalker error when I start to debug.
    "Error displaying local variables
    InstallPadWalker and restart Eclipse...."
    Windows PATH contains C:\Perl\site\bin;C:\Perl\bin; at the beginning.
    Do I still have to use the "special" padwalker from the epic pages?
    Is it still downloadable somewhere?

     
  • Jan Ploski

    Jan Ploski - 2007-04-27

    Logged In: YES
    user_id=86907
    Originator: NO

    Install PadWalker >1.0 - it should definitely be available via ppm in 5.8.8.x. There is no need for a special EPIC version of PadWalker any more, but you should use an up-to-date PadWalker.

     
  • mke

    mke - 2007-04-27

    Logged In: YES
    user_id=1775262
    Originator: NO

    working with PPM gui
    activestate only offer Padwalker 0.1.0
    using other repositories I loaded in 1.5 and 1.0
    (e.g. http://www.bribes.org/perl/ppm for 1.5)
    Same error as before with both of these...

     
  • mke

    mke - 2007-04-27

    Logged In: YES
    user_id=1775262
    Originator: NO

    working with PPM gui
    activestate only offers Padwalker 0.1.0
    using other repositories I loaded in 1.5 and 1.0
    (e.g. http://www.bribes.org/perl/ppm for 1.5)

    i get the same error as before with both of these
    "Error displaying local variables
    InstallPadWalker and restart Eclipse.."

    Could it be some issue with file structure of activestate?
    padwalker.pm under perl/site/lib,
    all other files under perl/site/lib/auto

    Apart from this debugging feels more solid. The stack is fully displayed.
    Will test some more tomorrow.

     
  • Jan Ploski

    Jan Ploski - 2007-04-27

    Logged In: YES
    user_id=86907
    Originator: NO

    I took a closer look at the code and discovered a fresh new bug which caused 0.6.1 to reject PadWalkers newer than 1.0 :(. Upgrade to 0.6.2 before any further tests...

     
  • Jan Ploski

    Jan Ploski - 2007-05-01

    Logged In: YES
    user_id=86907
    Originator: NO

    0.6.3 should be an even better target.

     
  • mke

    mke - 2007-05-03

    Logged In: YES
    user_id=1775262
    Originator: NO

    updated to 0.6.3
    1. stack displayed
    2. variables displayed
    3. breakpoints ok - but ignored(?) at top level (both absolute cgi and cgi/lib paths set in Perl Include Path)

    i kept having the same erratic crash / freeze effect in the debugger at random positions
    during the init of my first object... somewhere in the *inheritance stack*.

    now for the strange part.
    i use a simple logger object to look after a filehandle and print timestamped debug messages.
    i had 4 breakpoints in this code.

    on a whim, after very many crash/freezes, i removed just these breakpoints. and now i don't get the crashes anymore!

    Context FYI:
    1. the crashes/freezes occured somewhere during object instantiation, and generally not in the logger.
    (i can upload the perl -d console output file to show this)
    2. the logger is called at all stages of instantiation to output messages
    3. these files ARE created and content seems ok
    the question is why should the breakpoint removal make this difference?

    still getting the occassional crash/freeze - FAR fewer than before...
    testing continues...

     
  • Jan Ploski

    Jan Ploski - 2007-05-03

    Logged In: YES
    user_id=86907
    Originator: NO

    > the question is why should the breakpoint removal make this difference?

    A very good question indeed and it would help if you could provide output of the debugger console for both a crashing and not-crashing case, while executing the same steps in the UI to make them comparable. Even better would be if you could isolate the problem into a simple example which behaves erratically and post the code. But I guess that might be too much effort.

    EPIC only retrieves the stack content on suspends. So maybe there is something dumped in the stack content at these breakpoints which causes the crashes to occur.

     
  • mke

    mke - 2007-05-16

    Logged In: YES
    user_id=1775262
    Originator: NO

    The code I was debugging was very new and fragile
    After our last contact I placed CGI::Carp fatalstobrowser into the code
    and found for example the the central logger class i use to output timestamped debug messages
    (mentioned previously) did not have a "use filehandle" statement
    (outside the debugger the code did work despite this,
    with the debugger the code occassionally worked but mostly crashed randomly).
    There were other errors/warnings of this nature - which I corrected.
    My impression is that debugging after these corrections became much more normal,
    without the random crashes. So perhaps the behaviour is a consequence of missing
    use statements which are sometimes/sometimes not resolved during debugging...
    e.g. std lib location c:perl/lib
    Perhaps this is std behaviour of the cmd line perl debugger.
    Currently in non debug mode!(writing/refactoring)
    Will report later when code is "ready" to debug.

     
  • Jan Ploski

    Jan Ploski - 2007-05-27
    • status: open --> closed-fixed
     
  • Jan Ploski

    Jan Ploski - 2007-05-27

    Logged In: YES
    user_id=86907
    Originator: NO

    With a big number of internal changes in 0.6.5's debugger, I will close this bug report as "fixed" now and let you create some new ones ;-). It would be better if you reported each issue separately to make tracking fixes easier. 0.6.5 in particular contains a fix which should keep EPIC from ignoring breakpoints, regardless of whether you use 'require' or 'use', relative or absolute paths. However, I had no chance to test it under Windows.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks