[patch] Don't crash on stepping "bad frame"

[patch] Don't crash on stepping "bad frame"

[Mark Wielaard]

Hi,

While working on #5259 I noticed that the stepping engine crashes and
burns on x86_64 when a bad frame without unwind info is being stepped
into. This patch handles that case gracefully. And you can now safely
next through simple examples programs like funit-hello as we did in the
last demo - you can still drop into the wrong frame till #5259 is fixed
though.

frysk-core/frysk/stepping/ChangeLog
2008-02-29  Mark Wielaard  <mwielaard@redhat.com>

    * StepOverTestState.java (handleUpdate): Don't crash when there is
    a bad outer frame.

Committed,

Mark

--- a/frysk-core/frysk/stepping/StepOverTestState.java
+++ b/frysk-core/frysk/stepping/StepOverTestState.java
@@ -86,6 +86,16 @@ public class StepOverTestState extends State {
                 * it exits - success!
                 */
                Frame frame = newFrame.getOuter();
+               if (frame == null)
+                 {
+                   // But urgh... Where did our outer frame go...
+                   // We need to just try to keep stepping till we are
+                   // able to get a solid frame again.
+                   tse.getSteppingEngine().continueForStepping(this.task,
+                                                               true);
+                   return this;
+                 }
+
                tse.getSteppingEngine().setBreakpoint(this.task,
                        frame.getAddress());
                return new StepOverState(this.task);

Re: [patch] Don't crash on stepping "bad frame"

[Andrew Cagney]

Mark,

Interesting work-around; I'll add some comments to explain exactly 
where/when this senario occures.  And where/when it doesn't.  For 
instance a step-out through a sigalt stack, whith a bad unwind, will 
make the wrong decision.

Andrew

Mark Wielaard wrote:
> Hi,
>
> While working on #5259 I noticed that the stepping engine crashes and
> burns on x86_64 when a bad frame without unwind info is being stepped
> into. This patch handles that case gracefully. And you can now safely
> next through simple examples programs like funit-hello as we did in the
> last demo - you can still drop into the wrong frame till #5259 is fixed
> though.
>
> frysk-core/frysk/stepping/ChangeLog
> 2008-02-29  Mark Wielaard  <mwielaard@redhat.com>
>
>     * StepOverTestState.java (handleUpdate): Don't crash when there is
>     a bad outer frame.
>
> Committed,
>
> Mark
>
> --- a/frysk-core/frysk/stepping/StepOverTestState.java
> +++ b/frysk-core/frysk/stepping/StepOverTestState.java
> @@ -86,6 +86,16 @@ public class StepOverTestState extends State {
>                  * it exits - success!
>                  */
>                 Frame frame = newFrame.getOuter();
> +               if (frame == null)
> +                 {
> +                   // But urgh... Where did our outer frame go...
> +                   // We need to just try to keep stepping till we are
> +                   // able to get a solid frame again.
> +                   tse.getSteppingEngine().continueForStepping(this.task,
> +                                                               true);
> +                   return this;
> +                 }
> +
>                 tse.getSteppingEngine().setBreakpoint(this.task,
>                         frame.getAddress());
>                 return new StepOverState(this.task);
>
>
>   

Re: [patch] Don't crash on stepping "bad frame"

[Mark Wielaard]

Hi Andrew,

On Fri, 2008-02-29 at 11:02 -0500, Andrew Cagney wrote:
> Interesting work-around; I'll add some comments to explain exactly 
> where/when this senario occures.  And where/when it doesn't.  For 
> instance a step-out through a sigalt stack, whith a bad unwind, will 
> make the wrong decision.

Yes, please do add such documentation if you can. That would be very
valuable.

Note that there isn't any "good" decision really in the case of bad
unwind info where getOuterFrame() has to return null. Currently we try
to get the user back to "known territory", but we could also just drop
the user at the "bad address" and let them sort it out themselves.
Neither is really attractive of course.

Cheers,

Mark