Strange behavior with the fhpd

Strange behavior with the fhpd

[Adam Jocksch]

I've been encountering strange behavior with fhpd since I updated this 
morning. For some reason breakpoints are being hit, but the scope 
information and symbol table aren't behaving as they should. Here's an 
example session to show you what I mean: http://pastebin.ca/616520

Re: Strange behavior with the fhpd

[Stan Cox]

On Thu, 2007-07-12 at 11:58 -0600, Adam Jocksch wrote:
> I've been encountering strange behavior with fhpd since I updated this morning. 

Might be related to the current frame removal; looking now.

Re: Strange behavior with the fhpd

[Stan Cox]

Looks like a timing issue.  I think this is what is happening:

Currently:
frysk.cli.hpd.CLI.finishAttach -> frysk.stack.StackFactory.createFrame
(sometimes you end up only with start, this is Adam's problem)

Previously:
as above...but later
frysk.cli.hpd.CLI.refreshSymtab -> frysk.debuginfo.DebugInfo.refresh ->
frysk.debuginfo.DebugInfoEvaluator.refreshCurrentFrame ->
-> frysk.stack.StackFactory.createFrame

Looks like it will be necessary to either delay the setup of frame or
resurrect some form of the refresh machinery.

Re: Strange behavior with the fhpd

[Stan Cox]

On Thu, 2007-07-12 at 11:58 -0600, Adam Jocksch wrote:
> I've been encountering strange behavior with fhpd 

        * CLI.java (SteppingObserver.update): Update frame.

Re: Strange behavior with the fhpd

[Andrew Cagney]

Stan Cox wrote:
> Looks like a timing issue.  I think this is what is happening:
>
> Currently:
> frysk.cli.hpd.CLI.finishAttach -> frysk.stack.StackFactory.createFrame
> (sometimes you end up only with start, this is Adam's problem)
>
>   
I don't think it will be a timing issue.   Looking at this:

   1.
      [ajocksch@localhost frysk-core]$ frysk/bindir/fhpd
      /home/ajocksch/build/frysk/frysk-core/frysk/pkglibdir/funit-rt-varchange
   2.
      Attached to process 14184
   3.
      (fhpd) where
   4.
      #0 0x006a58d0 in _start ()

I'm surprised it is still in _start.

   1.
      (fhpd) break @funit-rt-varchange.c@52
   2.
      breakpoint 0
   3.
      (fhpd) go
   4.
      (fhpd) Breakpoint 0 @funit-rt-varchange.c@52
   5.
      where
   6.
      #0 0x006a58d0 in _start ()


A guess is that something is trying to be more efficient by caching 
locally instead of leaving it to a lower level.  This often happens when 
the LHS with refresh is fighting the RHS using on-demand.  I'd suggest a 
step sideways here and remove all caching for now; do everything on-demand.

   1.
      (fhpd) display x
   2.
      1: x = <unavailable>
   3.
      (fhpd)


> Previously:
> as above...but later
> frysk.cli.hpd.CLI.refreshSymtab -> frysk.debuginfo.DebugInfo.refresh ->
> frysk.debuginfo.DebugInfoEvaluator.refreshCurrentFrame ->
> -> frysk.stack.StackFactory.createFrame
>
> Looks like it will be necessary to either delay the setup of frame or
> resurrect some form of the refresh machinery.
>
>
>
>   

Re: Strange behavior with the fhpd

[Stan Cox]

With the patch committed last night that resurrects a simpler form of
the refresh machinery I get the following.  Mind you I didn't
investigate why it is in start prior to the refresh.

(fhpd) break bar
breakpoint 0
(fhpd) go
(fhpd) Breakpoint 0 bar
where
#0 0x00000000004004ae in bar ()
#1 0x0000000000400461 in main ()
#2 0x0000003c54a1daa4 in __libc_start_main ()
#3 0x0000000000400399 in _start ()
(fhpd) go
(fhpd) Breakpoint 0 bar
where
#0 0x00000000004004ae in bar ()
#1 0x0000000000400476 in main ()
#2 0x0000003c54a1daa4 in __libc_start_main ()
#3 0x0000000000400399 in _start ()
(fhpd) print x
1
(fhpd)