Problem with dbstep

[John Swensen]

First, I have to say that being able to step a line at a time is  
awesome.  However, Octave crashes when you try to dbstep past the end  
of a file.

test.m
--------
function a = test(b)

a=1*b;
a = 2*b;
a=3*b;


octave:1> dbstop('test',3);
octave:2> a=test(1)
debug> dbstep
<segfault occurs>

Here is the backtrace:
#0  0xb7a56534 in tree_statement::line (this=0x8313a60) at pt-stmt.cc:60
#1  0xb77bb63f in octave_call_stack::do_current_line (this=0xb7fb283c)  
at toplev.cc:103
#2  0xb763bd5d in get_debug_input (prompt=@0xbfb65530) at toplev.h:125
#3  0xb763c7ce in do_keyboard (args=@0xbfb6564c) at input.cc:866
#4  0xb7a2a7ed in tree_identifier::rvalue (this=0x81aec38, nargout=1)  
at pt-id.cc:60
#5  0xb7a2a059 in tree_identifier::rvalue (this=0x81aec38) at pt-id.cc:
109
#6  0xb7a5091f in tree_parameter_list::convert_to_const_vector  
(this=0x841de40, varargout=@0xbfb658b8)
     at pt-decl.h:68
#7  0xb78ee9ea in octave_user_function::do_multi_index_op  
(this=0x810d468, nargout=1, args=@0x8220ea0)
     at ov-usr-fcn.cc:510
#8  0xb78ef654 in octave_user_function::subsref (this=0x810d468,  
type=@0x820a4cc, idx=@0xbfb65b9c,
     nargout=1) at ov-usr-fcn.cc:337
#9  0xb78f0775 in octave_user_function::subsref (this=0x810d468,  
type=@0x820a4cc, idx=@0xbfb65b9c)
     at ov-usr-fcn.h:287
#10 0xb7888e32 in octave_value::subsref (this=0xbfb65bc4,  
type=@0x820a4cc, idx=@0xbfb65b9c, nargout=1)
     at ov.cc:1036
#11 0xb7a3157b in tree_index_expression::rvalue (this=0x820a4a8,  
nargout=1) at pt-idx.cc:385
#12 0xb7a2e7e9 in tree_index_expression::rvalue (this=0x820a4a8) at pt-
idx.cc:396
#13 0xb7a12df1 in tree_simple_assignment::rvalue (this=0x8215e60) at  
pt-assign.cc:202
#14 0xb7a11c00 in tree_simple_assignment::rvalue (this=0x8215e60,  
nargout=0) at pt-assign.cc:184
#15 0xb7a57281 in tree_statement::eval (this=0x8215e90, silent=false,  
nargout=0,
     in_function_or_script_body=false) at pt-stmt.cc:124
#16 0xb7a57953 in tree_statement_list::eval (this=0x84346a0,  
silent=true, nargout=0) at pt-stmt.cc:186
#17 0xb77c158f in main_loop () at toplev.cc:425
#18 0xb7746667 in octave_main (argc=1, argv=0xbfb66134, embedded=0) at  
octave.cc:852
#19 0x0804878a in main (argc=136088760, argv=0x635f6873) at main.c:35

John Swensen

[David Bateman]

John Swensen wrote:

> First, I have to say that being able to step a line at a time is
> awesome.  However, Octave crashes when you try to dbstep past the end
> of a file.
>
> test.m
> --------
> function a = test(b)
>
> a=1*b;
> a = 2*b;
> a=3*b;
>
>
> octave:1> dbstop('test',3);
> octave:2> a=test(1)
> debug> dbstep
> <segfault occurs>

Looking at the backtrace I assume that this is with a recent HG build..
Note that there were changes commited to the repository yesterday that
relate to these aspects. However, just testing this example it crashes
before and after applying these changes.

The fix is clearly that the pt-bp.h (MAYBE_DO_BREAKPOINT) macro has to
recognize that ta function is returning and not break or decrement its
counters. However, I'm not sure how that should be implemented. JWE what
is the means to check whether a function is returning in this macro?

D.



--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

[John W. Eaton]

On  9-Jul-2008, David Bateman wrote:

| Looking at the backtrace I assume that this is with a recent HG build..
| Note that there were changes commited to the repository yesterday that
| relate to these aspects. However, just testing this example it crashes
| before and after applying these changes.
|
| The fix is clearly that the pt-bp.h (MAYBE_DO_BREAKPOINT) macro has to
| recognize that ta function is returning and not break or decrement its
| counters. However, I'm not sure how that should be implemented. JWE what
| is the means to check whether a function is returning in this macro?

Yes, we need to decide what should happen when we are at the end of a
function and there is no next line to step to.  As a temporary fix, it
might be OK to just not allow stepping, but I think it would be
better to step to the next line in the calling function (if any) or
back to the top level prompt.  But I don't really understand the
debugging code very well, and I don't know what the proper fix is.

Also, I noticed that for the example function (which takes an argument)

  dbstop test
  test
  dbstep

also crashes Octave when it tries to print the error message and I
don't know what the proper fix is for that either.

jwe

[David Bateman]

John W. Eaton wrote:

> On  9-Jul-2008, David Bateman wrote:
>
> | Looking at the backtrace I assume that this is with a recent HG build..
> | Note that there were changes commited to the repository yesterday that
> | relate to these aspects. However, just testing this example it crashes
> | before and after applying these changes.
> |
> | The fix is clearly that the pt-bp.h (MAYBE_DO_BREAKPOINT) macro has to
> | recognize that ta function is returning and not break or decrement its
> | counters. However, I'm not sure how that should be implemented. JWE what
> | is the means to check whether a function is returning in this macro?
>
> Yes, we need to decide what should happen when we are at the end of a
> function and there is no next line to step to.  As a temporary fix, it
> might be OK to just not allow stepping, but I think it would be
> better to step to the next line in the calling function (if any) or
> back to the top level prompt.  But I don't really understand the
> debugging code very well, and I don't know what the proper fix is.
>
> Also, I noticed that for the example function (which takes an argument)
>
>   dbstop test
>   test
>   dbstep
>
> also crashes Octave when it tries to print the error message and I
> don't know what the proper fix is for that either.
>  

Forget it. The fix is easy.. As far as I see we shouldn't be testing for

a breakpoint for the lvalue or rvalue of a function definition. Just
removing the MAYBE_DO_BREAKPOINT from pt-id.cc fixes the issue. Patch
attached.

D.

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


# HG changeset patch
# User David Bateman <dbateman@...>
# Date 1215619791 -7200
# Node ID 42d92afd9fa2be9716c2e424f189d067b0b47f68
# Parent  c7fa906e597358bd6a2f11bafc457b317b6b6f76
Fix seg-fault for dbstep at end of function

diff --git a/src/ChangeLog b/src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,9 @@ 2008-07-08  John W. Eaton  <jwe@...
[phone]  David Bateman  <dbateman@...>
+
+ * pt-id.cc (octave_value_list tree_identifier::rvalue (int),
+ octave_lvalue tree_identifier::lvalue (void)): Remove
+ MAYBE_DO_BREAKPOINT.
+
 2008-07-08  John W. Eaton  <jwe@...>
 
  * graphics.h.in (axes::properties::keypos): Declare as
diff --git a/src/pt-id.cc b/src/pt-id.cc
--- a/src/pt-id.cc
+++ b/src/pt-id.cc
@@ -57,8 +57,6 @@ tree_identifier::rvalue (int nargout)
 {
   octave_value_list retval;
 
-  MAYBE_DO_BREAKPOINT;
-
   if (error_state)
     return retval;
 
@@ -117,8 +115,6 @@ octave_lvalue
 octave_lvalue
 tree_identifier::lvalue (void)
 {
-  MAYBE_DO_BREAKPOINT;
-
   return octave_lvalue (&(xsym().varref ()));
 }
 

[John W. Eaton]

On  9-Jul-2008, David Bateman wrote:

| Forget it. The fix is easy.. As far as I see we shouldn't be testing for
| a breakpoint for the lvalue or rvalue of a function definition. Just
| removing the MAYBE_DO_BREAKPOINT from pt-id.cc fixes the issue. Patch
| attached.

I applied it.

Thanks,

jwe