dbstop doesn't break with run script

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

dbstop doesn't break with run script

Jordi Gutiérrez Hermoso-2
If you do

    dbstop foo 5

and a breakpoint is set and later type

    run foo.m

the breakpoint isn't hit. Is this a bug?

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

dbstop doesn't break with run script

John W. Eaton
Administrator
On 25-May-2011, Jordi Gutiérrez Hermoso wrote:

| If you do
|
|     dbstop foo 5
|
| and a breakpoint is set and later type
|
|     run foo.m
|
| the breakpoint isn't hit. Is this a bug?

Here's what I think is happening:

When you set the breakpoint, Octave finds the function or script foo.
If it is not already in the symbol table, it parses it, then tags the
function's parse tree with the debug breakpoint.  Then if you type

  foo

to execute the script, Octave will find it in the symbol table and
execute the already parsed version of the script with the debugging
info, so you'll end up stopping at the breakpoint you set.

When you use the run function to execute the script, it ultimately
calls

        evalin ("caller", sprintf ("source (\"%s\");", script),
                "rethrow (lasterror ())");

to evaluate "./foo.m".  The source function does not look for
"./foo.m" in the symbol table, but instead unconditionally parses the
file and executes the resulting parse tree object, which does not have
the debugging info attached to it.

If you think it is a bug that should be fixed, then I think we need to
either change the source function to look for functions and scripts in
the symbol table first before parsing the file again, or have some
other way of executing functions that can look in the symbol table
first.  We would need to be able to find the function regardless of
how the name is specified to the run function.  I don't remember
precisely how functions and scripts are stored in the symbol table, so
I don't know whether the full path name is used as a key, or if it is
simple to search using that information.

BTW, it looks to me like the evalin above could simplified by using

  source (script, "caller");

now, but this will not solve the problem you are seeing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: dbstop doesn't break with run script

Jordi Gutiérrez Hermoso-2
2011/5/25 John W. Eaton <[hidden email]>:

> On 25-May-2011, Jordi Gutiérrez Hermoso wrote:
>
> | If you do
> |
> |     dbstop foo 5
> |
> | and a breakpoint is set and later type
> |
> |     run foo.m
> |
> | the breakpoint isn't hit. Is this a bug?
>
> Here's what I think is happening:
>
> When you set the breakpoint, Octave finds the function or script foo.
> If it is not already in the symbol table, it parses it, then tags the
> function's parse tree with the debug breakpoint.  Then if you type
>
>  foo
>
> to execute the script, Octave will find it in the symbol table and
> execute the already parsed version of the script with the debugging
> info, so you'll end up stopping at the breakpoint you set.
>
> When you use the run function to execute the script, it ultimately
> calls
>
>        evalin ("caller", sprintf ("source (\"%s\");", script),
>                "rethrow (lasterror ())");
>
> to evaluate "./foo.m".  The source function does not look for
> "./foo.m" in the symbol table, but instead unconditionally parses the
> file and executes the resulting parse tree object, which does not have
> the debugging info attached to it.

Thanks, I opened a bug and assigned it to myself. This is a good
excuse for me to learn more about how the parser works:

     https://savannah.gnu.org/bugs/?33411

- Jordi G. H.