* Strange behavior with the fhpd
@ 2007-07-12 17:58 Adam Jocksch
2007-07-12 20:19 ` Stan Cox
2007-07-13 3:17 ` Stan Cox
0 siblings, 2 replies; 6+ messages in thread
From: Adam Jocksch @ 2007-07-12 17:58 UTC (permalink / raw)
To: frysk
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Strange behavior with the fhpd
2007-07-12 17:58 Strange behavior with the fhpd Adam Jocksch
@ 2007-07-12 20:19 ` Stan Cox
2007-07-12 23:14 ` Stan Cox
2007-07-13 3:17 ` Stan Cox
1 sibling, 1 reply; 6+ messages in thread
From: Stan Cox @ 2007-07-12 20:19 UTC (permalink / raw)
To: Frysk List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Strange behavior with the fhpd
2007-07-12 20:19 ` Stan Cox
@ 2007-07-12 23:14 ` Stan Cox
2007-07-13 13:23 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Stan Cox @ 2007-07-12 23:14 UTC (permalink / raw)
To: Frysk List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Strange behavior with the fhpd
2007-07-12 17:58 Strange behavior with the fhpd Adam Jocksch
2007-07-12 20:19 ` Stan Cox
@ 2007-07-13 3:17 ` Stan Cox
1 sibling, 0 replies; 6+ messages in thread
From: Stan Cox @ 2007-07-13 3:17 UTC (permalink / raw)
To: Adam Jocksch; +Cc: frysk
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Strange behavior with the fhpd
2007-07-12 23:14 ` Stan Cox
@ 2007-07-13 13:23 ` Andrew Cagney
2007-07-13 19:47 ` Stan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2007-07-13 13:23 UTC (permalink / raw)
To: Frysk List
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.
>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Strange behavior with the fhpd
2007-07-13 13:23 ` Andrew Cagney
@ 2007-07-13 19:47 ` Stan Cox
0 siblings, 0 replies; 6+ messages in thread
From: Stan Cox @ 2007-07-13 19:47 UTC (permalink / raw)
To: Frysk List
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-07-13 19:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-12 17:58 Strange behavior with the fhpd Adam Jocksch
2007-07-12 20:19 ` Stan Cox
2007-07-12 23:14 ` Stan Cox
2007-07-13 13:23 ` Andrew Cagney
2007-07-13 19:47 ` Stan Cox
2007-07-13 3:17 ` Stan Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).