This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: Strange behavior with the fhpd
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.