[Bug breakpoints/16551] New: Execution stops when encountering a dprintf with an invalid string

[Bug breakpoints/16551] New: Execution stops when encountering a dprintf with an invalid string

[marc.khouzam at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

            Bug ID: 16551
           Summary: Execution stops when encountering a dprintf with an
                    invalid string
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: marc.khouzam at ericsson dot com

I define a dprintf that has an error in its printout function (as the user may
do this by mistake).  When the dprintf is hit, an error printout is output and
the execution stops.  However, no *stopped event is issued.

This missing *stopped event is not good, but I think the problem to fix is that
the execution should not stop in this case.  If a user sets a dprintf, she
expects the execution to continue and there may be negative consequence at
suddenly stopping the execution.

Addressing bug 15185 would probably fix this.

Here is a stripped session that shows how to reproduce:

> gdb -i mi loopfirst
=thread-group-added,id="i1"
~"GNU gdb (GDB) 7.7\n"
~"Reading symbols from loopfirst..."
~"done.\n"
(gdb) 
dprintf 5,"%d\n",badvariable
(gdb) 
i b
&"i b\n"
~"Num     Type           Disp Enb Address            What\n"
~"1       dprintf        keep y   0x000000000040054c in main() at
loopfirst.cc:5\n"
~"        printf \"%d\\n\",badvariable\n"
^done
(gdb) 
22-exec-run
=thread-group-started,id="i1",pid="13398"
=thread-created,id="1",group-id="i1"
22^running
*running,thread-id="all"
(gdb)
22^error,msg="No symbol \"badvariable\" in current context."
(gdb)
i thre
&"i thre\n"
~"  Id   Target Id         Frame \n"
~"* 1    process 13398 \"loopfirst\" main () at loopfirst.cc:5\n"
^done

=== Notice that the thread is stopped although we did an -exec-run ==

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string

[malaperle at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

Marc-Andre Laperle <malaperle at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |malaperle at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string

[antoine.tremblay at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

Antoine Tremblay <antoine.tremblay at ericsson dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |antoine.tremblay at ericsson dot c
                   |                            |om
           Assignee|unassigned at sourceware dot org   |antoine.tremblay at ericsson dot c
                   |                            |om

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string

[antoine.tremblay at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

--- Comment #1 from Antoine Tremblay <antoine.tremblay at ericsson dot com> ---
After some research in gdb it seems to me that the expectation is that if a
command fails gdb returns to prompt in it's current execution state.
The expectation of the developer should be that if a command input is wrong,
gdb
can't do what the user requested and control is returned to the developer
to fix the error.

This seems consistent accross all commands in gdb... I think changing that
a dprintf fails with an error to a warning and allowing the program to continue
could break this consistency and be more trouble for the developer as he won't
be given a chance to fix the issue as soon as possible during his debugging
session. He would have to wait until the end of the execution. 

Also, the fact that he called exec-run only gives the developer the expectation
that gdb will continue until it reaches a breakpoint, and a dprintf is
consired a breakpoint in that sense, so it should not be unexpected
for the developer that dprintf can stop the execution in case of failure.

I'm also uncertain about what you mean by the stopped event beeing missed ?

As dprintf is called by a stop event...

Also bug 15185 would not fix the isssue since we can only know about the bad 
symbol at the runtime of that line since shared libraries could be loaded
dynamicaly thus we can't prevalidate the dprintf input as we enter it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string

[marc.khouzam at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

--- Comment #2 from Marc Khouzam <marc.khouzam at ericsson dot com> ---
(In reply to Antoine Tremblay from comment #1)

> The expectation of the developer should be that if a command input is wrong,
> gdb
> can't do what the user requested and control is returned to the developer
> to fix the error.

Ok, that makes sense.

> I'm also uncertain about what you mean by the stopped event beeing missed ?

I think a dprintf is treated as an internal breakpoint, so when one is hit,
there is no *stopped event that Eclipse can see.  This makes sense because we
expect the execution to resume.  However, in this case, the execution of the
thread that hit the dprintf stayes suspended but we don't notify eclipse (with
a *stopped event) so eclipse still shows everything as running, and things get
stuck.

> Also bug 15185 would not fix the isssue since we can only know about the bad
> symbol at the runtime of that line since shared libraries could be loaded
> dynamicaly thus we can't prevalidate the dprintf input as we enter it.

It does seem like it would not be possible, but gdb is able to do some checking
when we set conditions.  I was hoping we could do something similar?  I'll put
a note in the relevant bug:

(gdb) b 9 if ii<0
No symbol "ii" in current context.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string

[antoine.tremblay at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

--- Comment #3 from Antoine Tremblay <antoine.tremblay at ericsson dot com> ---
After much thought and some discussion on the gdb ml...

There was a few options :

Having a generic *stopped,error="xxx" event : was ruled out due to the
complexity of making this generic in gdb... unfortuanately we can't update the
thread state properly in case of error because of implementation details see :
https://sourceware.org/ml/gdb-patches/2015-02/msg00701.html

Having an *error aync message : This seemed like a good idea but it would
impact all the calls to print_exception, to be mi aware and sync/async aware
too, it seems like a bad idea code wise to mix that code.

We're left with the option to treat messages that start with "&" as a signal to
let the frontend know it should refresh it state.

I think this is the best option now since it basically does what the *error
async message would do and it's already implemented cleanly in gdb.

Note that the "&" prefix is directly associated with a print to stderr in gdb,
so we can safely assume it's an error signal.

So opon receiving a message starting with & the front end would refresh it's
state..

Marc does that sounds like an option for eclipse ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string

[marc.khouzam at ericsson dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16551

--- Comment #4 from Marc Khouzam <marc.khouzam at ericsson dot com> ---
(In reply to Antoine Tremblay from comment #3)

> So opon receiving a message starting with & the front end would refresh it's
> state..
> 
> Marc does that sounds like an option for eclipse ?

We'll give that a try and report back.

Thanks for the investigation!

-- 
You are receiving this mail because:
You are on the CC list for the bug.