Re: Strange behavior with the fhpd

[Andrew Cagney <cagney@redhat.com>]

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.
>
>
>
>