octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with debugger in Octave


From: Rik
Subject: Re: Problems with debugger in Octave
Date: Mon, 05 Nov 2012 08:34:57 -0800

On 11/03/2012 03:28 PM, address@hidden wrote:
> Message: 2 Date: Sat, 03 Nov 2012 20:31:13 +0000 From: Richard Crozier
> <address@hidden> To: Max Brister <address@hidden> Cc: Jordi
> Guti?rrez Hermoso <address@hidden>, Octave Maintainers List
> <address@hidden> Subject: Re: 4.0 release goals
> Message-ID: <address@hidden> Content-Type: text/plain;
> charset="iso-8859-1"; Format="flowed" On 03/11/2012 19:55, Max Brister
> wrote:
>> > On Sat, Nov 3, 2012 at 7:01 AM, Richard <address@hidden 
>> > <mailto:address@hidden>> wrote:
>> >
>> >     On 01/11/2012 18:31, Jordi Guti?rrez Hermoso wrote:
>> >
>> >         On 1 November 2012 13:54, Lukas Reichlin
>> >         <address@hidden
>> >         <mailto:address@hidden>> wrote:
>> >
>> >             On 01.11.2012, at 17:59, Jordi Guti?rrez Hermoso
>> >             <address@hidden <mailto:address@hidden>> wrote:
>> >
>> >             My point being, GUI should be the biggest priority, let's
>> >             stabilise it so we can make an awesome 4.0 splash. - Jordi
>> >             G. H.
>> >
>> >
>> >     Um, on this point, is it a known thing that debugging doesn't work
>> >     in the editor/GUI?
>> >
>> >     For me the interactive debugging through the GUI is the primary
>> >     feature. At the moment, on my machine at least using the default
>> >     branch, the debugging works so badly through the editor buttons
>> >     that I would suggest any GUI release should actually remove the
>> >     buttons to avoid looking bad. I presume this is just a matter of
>> >     ongoing development work though, and this is known and not
>> >     specific to my setup?
>> >
>> >     Richard
>> >
>> >
>> > I did recently fix a bug in JIT that caused some breakpoints to be 
>> > ignored (http://hg.savannah.gnu.org/hgweb/octave/rev/52df2e7baabe). 
>> > Was this causing you problems, or is there some other issue?
>> >
>> > -- 
>> > Max Brister
> I compiled without JIT, so I don't know if its related.
>
> Adding break points through the editor works, the debugger stops at the 
> break point. However, once I am stopped at a break point and try to use 
> the editor buttons to step through etc. they do not work as expected. I 
> would need to sit and try things out to figure out exactly what happens, 
> but in general on clicking the dbstep button after stopping at a break 
> point, all the debug buttons are deactivated, and the command is ignored 
> in the Octave. There is then though further strange behaviour reported 
> in the Octave terminal, with strange locations being reported by the 
> debug output.
>
> I have other problems with debugging though, as reported in bug #37574. 
> Maybe it is something with my setup? This is running Octave using 
> ./run-octave
11/5/12

Richard,

The issue that you identified in bug #37574 is real.  It's actually
something of a definitional one.  When using
debug_on_warning/debug_on_error Octave makes the assumption that you want a
one-shot breakpoint.  It assumes that if you get an error and drop into the
debugger prompt that the only useful thing to do is inspect variables. 
Presumably, the error was significant enough that continuing, by using
dbstep, is not a real possibility so it treats it as dbcont and returns to
the Octave prompt.

I started looking into the problem and then got distracted when I noticed
that 'dbstep N' actually was executing 'dbstep N-1'.  I've fixed that and I
have an almost working solution for bug #37574.  I will post the patch up
on the bug tracker and also CC jwe to see if he likes the patch or can
think of a better way to do it.

--Rik
>
> Richard



reply via email to

[Prev in Thread] Current Thread [Next in Thread]