Debugger bugfix

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugger bugfix

John Swensen
Attached is a changeset to fix a bug I encountered in the debugger.  
The problem was in the bp_table::do_get_breakpoint_list(...) function  
where there is a loop over an STL iterator which calls  
out_of_date_check() in each iteration.  The problem occurred because  
out_of_date_check(), in turn, will call  
remove_all_breakpoints_in_file() when the file has changed, which  
modifies the object STL map being iterated over.

So I added another set of loops to take care of processing out-of-date  
breakpoints before building up the list of breakpoints for dbstatus().

John Swensen




debug.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debugger bugfix

David Bateman-3
John Swensen wrote:

> Attached is a changeset to fix a bug I encountered in the debugger.  
> The problem was in the bp_table::do_get_breakpoint_list(...) function
> where there is a loop over an STL iterator which calls
> out_of_date_check() in each iteration.  The problem occurred because
> out_of_date_check(), in turn, will call
> remove_all_breakpoints_in_file() when the file has changed, which
> modifies the object STL map being iterated over.
>
> So I added another set of loops to take care of processing out-of-date
> breakpoints before building up the list of breakpoints for dbstatus().
>
> John Swensen
>
>
John,

This patch looks right to me, but can you give an example of Octave code
that causes the bug to manifest? Is this related to the thread

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-September/008657.html

and continued in

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-October/008831.html

Cheers
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)

The information contained in this communication has been classified as:

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

Reply | Threaded
Open this post in threaded view
|

Re: Debugger bugfix

John Swensen

On Nov 24, 2008, at 5:26 AM, David Bateman wrote:

> John Swensen wrote:
>> Attached is a changeset to fix a bug I encountered in the  
>> debugger.  The problem was in the  
>> bp_table::do_get_breakpoint_list(...) function where there is a  
>> loop over an STL iterator which calls out_of_date_check() in each  
>> iteration.  The problem occurred because out_of_date_check(), in  
>> turn, will call remove_all_breakpoints_in_file() when the file has  
>> changed, which modifies the object STL map being iterated over.
>>
>> So I added another set of loops to take care of processing out-of-
>> date breakpoints before building up the list of breakpoints for  
>> dbstatus().
>>
>> John Swensen
>>
>>
> John,
>
> This patch looks right to me, but can you give an example of Octave  
> code that causes the bug to manifest? Is this related to the thread
>
> http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-September/008657.html
>
> and continued in
>
> http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-October/008831.html
>
> Cheers
> David
>
> --
> David Bateman                                
> [hidden email]
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)  
> Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)  
> 91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)
> The information contained in this communication has been classified  
> as:
> [x] General Business Information [ ] Motorola Internal Use Only [ ]  
> Motorola Confidential Proprietary
>

I don't think this bug had anything to do with those threads.  This  
was much more basic.  Try the following:

1) Add a breakpoint to a function
2) Call dbstatus
3) Modify the file in which the breakpoint was set (e.g. add and empty  
new line)
4) Call dbstatus and watch octave crash

I think the behavior is unique to dbstatus because it was modifying  
the STL::map while in the middle of iterating through it, because of  
the out of date check on the file.

John Swensen

Reply | Threaded
Open this post in threaded view
|

Re: Debugger bugfix

David Bateman-2
John Swensen wrote:
>
> I don't think this bug had anything to do with those threads.  

Sad, I would have liked to see that fixed :-) ..

> This was much more basic.  Try the following:
>
> 1) Add a breakpoint to a function
> 2) Call dbstatus
> 3) Modify the file in which the breakpoint was set (e.g. add and empty
> new line)
> 4) Call dbstatus and watch octave crash
>
> I think the behavior is unique to dbstatus because it was modifying
> the STL::map while in the middle of iterating through it, because of
> the out of date check on the file.
>
Ok, I applied this..

D.

--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: Debugger bugfix

John Swensen

On Nov 28, 2008, at 6:14 PM, David Bateman wrote:

> John Swensen wrote:
>>
>> I don't think this bug had anything to do with those threads.
>
> Sad, I would have liked to see that fixed :-) ..
>
>> This was much more basic.  Try the following:
>>
>> 1) Add a breakpoint to a function
>> 2) Call dbstatus
>> 3) Modify the file in which the breakpoint was set (e.g. add and  
>> empty new line)
>> 4) Call dbstatus and watch octave crash
>>
>> I think the behavior is unique to dbstatus because it was modifying  
>> the STL::map while in the middle of iterating through it, because  
>> of the out of date check on the file.
>>
> Ok, I applied this..
>
> D.
>
> --
> David Bateman                                [hidden email]
> 35 rue Gambetta                              +33 1 46 04 02 18 (Home)
> 92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)
>

Do you have some concrete examples of where these two cases from the  
previous threads were failing, so I can start hunting this down?  I  
keep telling myself I need to work on something that forces me to get  
to understand how the code is parsed and stored, and maybe this is my  
chance to bite the bullet.

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: Debugger bugfix

David Bateman-2
John Swensen wrote:
>
> Do you have some concrete examples of where these two cases from the
> previous threads were failing, so I can start hunting this down?  I
> keep telling myself I need to work on something that forces me to get
> to understand how the code is parsed and stored, and maybe this is my
> chance to bite the bullet.
I can no longer reproduce easily the first issue I had, with misreported
locations of errors in if/for, etc blocks. Perhaps John check in a
change that fixed it in the last few weeks.

As for the second one, I thought the issue was generic and any block
would cause this issue. However it appears to only happen in methods of
classes. So consider we have a class constructor @cls/cls.m with the
contents

function b = cls (a)
  if (nargin < 1 || nargin > 2)
    print_usage ();
  else
    b.a = a;
    b.b = "cls";
    b = class (b, "cls");
  endif
end

Then here is an example with this  simple class

octave:2> a = cls(1)
octave:3> dbstop cls
ans =  2
octave:4> a = cls(1)
octave:5> dbstatus ()
octave:6>

This appears to happen in all methods of classes. However now consider

octave:6> dbstop("cls",5)
ans =  5
octave:7> a = cls(1)
cls: line 5, column 9
b.a = a
keyboard: stopped in /home/dbateman/octave/devel/classes/@cls/cls.m at
line 5
debug>

So setting the breakpoint somewhere that isn't on a if/while/for, etc
lock works fine.  Didn't look very far into this one.

Regards
David

--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)