Debug view receives verbose GDB messages

Aetf 7437103 at gmail.com
Sat Aug 20 18:16:01 UTC 2016


No Problem, my pleasure to contribute!

Cheers,
Peifeng Yu

On Sat, Aug 20, 2016 at 10:51 PM Kevin Funk <kfunk at kde.org> wrote:

> On Tuesday, 16 August 2016 21:38:02 CEST Jeremy Murphy wrote:
> > I can confirm that it is fixed on the 5.0 branch now. Thanks!
>
> Thanks a ton Peifeng!
>
> Cheers,
> Kevin
>
> > Jeremy
> >
> > On 14 August 2016 at 14:17, Aetf <7437103 at gmail.com> wrote:
> > > Hey Jeremy,
> > >
> > > On Sat, Aug 13, 2016 at 7:12 PM Jeremy Murphy <
> > >
> > > jeremy.william.murphy at gmail.com> wrote:
> > >> Hi Peifeng Yu,
> > >>
> > >> have you merged this fix?  I just synced with the 5.0 branch and the
> > >> verbose debugging output remains.
> > >
> > > The change is on master now. You can try it on the master branch. I'm
> not
> > > familiar with the develop status on 5.0 branch though, so I'm not sure
> if
> > > I
> > > can push directly to that branch. Anyway, I've opened a RR [1] for the
> fix
> > > on 5.0 branch.
> > >
> > > [1] https://phabricator.kde.org/D2440
> > >
> > > Thanks for looking into it, cheers.
> > >
> > >
> > > No problem :)
> > >
> > > Cheers,
> > > Peifeng Yu
> > >
> > >> Jeremy
> > >>
> > >> On 13 August 2016 at 02:59, Aetf <7437103 at gmail.com> wrote:
> > >>> Hey,
> > >>>
> > >>> I just checked the code, and realized that actually I've already
> added
> > >>> code showing exit reason to the Debug view as well as debugger
> console,
> > >>> maybe during my first refactor of the code. So I just stopped routing
> > >>> console stream into Debug view and everything works perfectly.
> > >>>
> > >>> Now you can get the following exit notifications in the Debug view:
> > >>>
> > >>> Exited with return code: 123
> > >>> Exited normally
> > >>> Exited on signal SIGXXX
> > >>> Program received signal SIGXXX (Human readable name)
> > >>>
> > >>> Cheers,
> > >>> Peifeng Yu
> > >>>
> > >>> On Wed, Jul 27, 2016 at 3:38 AM Aetf <7437103 at gmail.com> wrote:
> > >>>> Sure, but maybe not very soon. My deadline for GSoC is approaching,
> so
> > >>>> I have to focus on LLDB plugin now.
> > >>>>
> > >>>> Cheers,
> > >>>> Peifeng Yu
> > >>>>
> > >>>> On Tue, Jul 26, 2016 at 3:26 PM Kevin Funk <kfunk at kde.org> wrote:
> > >>>>> On Tuesday, July 26, 2016 7:17:15 PM CEST Aetf wrote:
> > >>>>> > The debugger console stream contains not only general debugger
> > >>>>>
> > >>>>> output, but
> > >>>>>
> > >>>>> > also some output generated by commands issued internally by
> > >>>>> > kdevelop.
> > >>>>> > That's why Jeremy seeing the help text and signal table when
> using
> > >>>>>
> > >>>>> 4.x
> > >>>>>
> > >>>>> > version.
> > >>>>> >
> > >>>>> > Though it's not hard to restore the behavior without break the
> > >>>>> > applicationOutput signal again, if the only reason for getting
> > >>>>>
> > >>>>> console
> > >>>>>
> > >>>>> > stream to Debug view is to get why program stopped, I think there
> > >>>>>
> > >>>>> should be
> > >>>>>
> > >>>>> > a better way than this. As gdb actually reports the stop reason
> via
> > >>>>>
> > >>>>> MI
> > >>>>>
> > >>>>> > protocol (*stopped,reason="..."), we could use that info to give
> a
> > >>>>>
> > >>>>> more
> > >>>>>
> > >>>>> > readable output in Debug view, rather than dump all console
> stream
> > >>>>>
> > >>>>> into
> > >>>>>
> > >>>>> > Debug view, which is meant to be application output.
> > >>>>>
> > >>>>> I'm fine with this approach, could you work on that maybe?
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Kevin
> > >>>>>
> > >>>>> > Cheers,
> > >>>>> > Peifeng Yu
> > >>>>> >
> > >>>>> > On Tue, Jul 26, 2016 at 2:58 PM Kevin Funk <kfunk at kde.org>
> wrote:
> > >>>>> > > On Tuesday, July 26, 2016 4:05:51 PM CEST Aetf wrote:
> > >>>>> > > > Hi,
> > >>>>> > > >
> > >>>>> > > > In fact I know this issue. It's because debugger console
> stream
> > >>>>>
> > >>>>> was
> > >>>>>
> > >>>>> > > > redirected to application output in commit 609bacd7 (by Kevin
> > >>>>>
> > >>>>> XD), so I
> > >>>>>
> > >>>>> > > > tried to keep the same behavior when cleaning up. Apparently
> > >>>>>
> > >>>>> there's
> > >>>>>
> > >>>>> > > > something I missed.
> > >>>>> > > >
> > >>>>> > > > We should rethink what kind of outputs we want to show in
> Debug
> > >>>>>
> > >>>>> view.
> > >>>>>
> > >>>>> > > > Currently, the outputs are routed like:
> > >>>>> > > >    1. - Application output             -> debugger target
> > >>>>>
> > >>>>> stream  ->
> > >>>>>
> > >>>>> > > >    applicationOutput signal      -> Debug View
> > >>>>> > > >    2. - Internal command line
> > >>>>>
> > >>>>>  ->
> > >>>>>
> > >>>>> > > >    internalCommandOutput signal  -> Debug View, GDB Console
> > >>>>> > > >    3. - Internal command output part 1 -> debugger console
> > >>>>>
> > >>>>> stream ->
> > >>>>>
> > >>>>> > > >    internalCommandOutput signal  -> Debug View, GDB Console
> > >>>>> > > >    4. - Internal command output part 2 -> debugger result
> > >>>>>
> > >>>>> record  ->
> > >>>>>
> > >>>>> > > >    internalCommandOutput signal  -> Debug View, GDB Console
> > >>>>> > > >    5. - User command line
> > >>>>>
> > >>>>>  ->
> > >>>>>
> > >>>>> > > >    userCommandOutput signal      -> GDB Console
> > >>>>> > > >    6. - User command output            -> debugger console
> > >>>>>
> > >>>>> stream ->
> > >>>>>
> > >>>>> > > >    userCommandOutput signal      -> GDB Console
> > >>>>> > > >    7. - Debugger internal log          -> debugger log stream
> > >>>>>
> > >>>>>  ->
> > >>>>>
> > >>>>> > > >    debuggerInternalOutput signal -> GDB Console
> > >>>>> > > >
> > >>>>> > > > Previous behavior was:
> > >>>>> > > >    1. - Application output             -> debugger target
> > >>>>>
> > >>>>> stream  ->
> > >>>>>
> > >>>>> > > >    applicationOutput signal      -> Debug View
> > >>>>> > > >    2. - Internal command line
> > >>>>>
> > >>>>>  ->
> > >>>>>
> > >>>>> > > >    internalCommandOutput signal  -> GDB Console
> > >>>>> > > >    3. - Internal command output part 1 -> debugger console
> > >>>>>
> > >>>>> stream ->
> > >>>>>
> > >>>>> > > >    applicationOutput signal      -> Debug View
> > >>>>> > > >    4. - Internal command output part 2 -> debugger result
> > >>>>>
> > >>>>> record  ->
> > >>>>>
> > >>>>> > > >    internalCommandOutput signal  -> GDB Console
> > >>>>> > > >    5. - User command line
> > >>>>>
> > >>>>>  ->
> > >>>>>
> > >>>>> > > >    userCommandOutput signal      -> GDB Console
> > >>>>> > > >    6. - User command output            -> debugger console
> > >>>>>
> > >>>>> stream ->
> > >>>>>
> > >>>>> > > >    userCommandOutput signal      -> GDB Console
> > >>>>> > > >    7. - Debugger internal log          -> debugger log stream
> > >>>>>
> > >>>>>  ->
> > >>>>>
> > >>>>> > > >    debuggerInternalOutput signal -> GDB Console
> > >>>>> > > >
> > >>>>> > > > In my opinion, we really should only have application output
> > >>>>>
> > >>>>> routed to
> > >>>>>
> > >>>>> > > the
> > >>>>> > >
> > >>>>> > > > Debug view. What do you think?
> > >>>>> > >
> > >>>>> > > If you look at my commit message in 609bacd7:
> > >>>>> > >
> > >>>>> > > commit 609bacd7f1a94a1aae9518718b5b175ece67141c
> > >>>>> > > Author: Kevin Funk <kfunk at kde.org>
> > >>>>> > > Date:   Fri Jan 15 01:46:15 2016 +0100
> > >>>>> > >
> > >>>>> > >     GDB: Merge console stream into Debug View
> > >>>>> > >
> > >>>>> > >     So you get crucial information during debugging, for
> example:
> > >>>>> > >
> > >>>>> > >     [Thread debugging using libthread_db enabled]
> > >>>>> > >     Using host libthread_db library
> > >>>>> > >     "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > >>>>> > >     [New Thread 0x7ffff6f4f700 (LWP 19219)]
> > >>>>> > >     Program received signal
> > >>>>> > >     SIGABRT, Aborted.
> > >>>>> > >     0x00007ffff6f85267 in __GI_raise (sig=sig at entry=6) at
> > >>>>> > >     ../sysdeps/unix/sysv/linux/raise.c:55
> > >>>>> > >
> > >>>>> > > => There needs to some way to see whether the program stopped,
> and
> > >>>>>
> > >>>>> why.
> > >>>>>
> > >>>>> > > I think the behavior in 609bacd7 was fine, both the application
> > >>>>>
> > >>>>> out +
> > >>>>>
> > >>>>> > > general
> > >>>>> > > debugger information was printed in the Debug view. We
> definitely
> > >>>>>
> > >>>>> don't
> > >>>>>
> > >>>>> > > want
> > >>>>> > > to see the GDB MI communication, though.
> > >>>>> > >
> > >>>>> > > Can't we get this behavior back?
> > >>>>> > >
> > >>>>> > > Unfortunately I'm not really on top of what you changed; I'd
> need
> > >>>>>
> > >>>>> to dig
> > >>>>>
> > >>>>> > > through your changes.
> > >>>>> > >
> > >>>>> > > Cheers,
> > >>>>> > > Kevin
> > >>>>> > >
> > >>>>> > > > Cheers,
> > >>>>> > > >
> > >>>>> > > > Peifeng Yu
> > >>>>> > > >
> > >>>>> > > > On Tue, Jul 26, 2016, 03:12 Jeremy Murphy <
> > >>>>> > >
> > >>>>> > > jeremy.william.murphy at gmail.com>
> > >>>>> > >
> > >>>>> > > > wrote:
> > >>>>> > > > > I just reverted to 4.90.91 and the output is quite
> different.
> > >>>>>
> > >>>>> I've
> > >>>>>
> > >>>>> > > > > completely abbreviated the actual program output and some
> > >>>>>
> > >>>>> verbose
> > >>>>>
> > >>>>> > > > > templates
> > >>>>> > > > > in the line where it hits a breakpoint:
> > >>>>> > > > >
> > >>>>> > > > >
> > >>>>> > > > > GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1
> > >>>>> > > > > Copyright (C) 2016 Free Software Foundation, Inc.
> > >>>>> > > > > License GPLv3+: GNU GPL version 3 or later <
> > >>>>> > > > > http://gnu.org/licenses/gpl.html>
> > >>>>> > > > > This is free software: you are free to change and
> redistribute
> > >>>>>
> > >>>>> it.
> > >>>>>
> > >>>>> > > > > There is NO WARRANTY, to the extent permitted by law.  Type
> > >>>>>
> > >>>>> "show
> > >>>>>
> > >>>>> > > copying"
> > >>>>> > >
> > >>>>> > > > > and "show warranty" for details.
> > >>>>> > > > > This GDB was configured as "x86_64-pc-linux-gnu".
> > >>>>> > > > > Type "show configuration" for configuration details.
> > >>>>> > > > > For bug reporting instructions, please see:
> > >>>>> > > > > <https://bugs.gentoo.org/>.
> > >>>>> > > > > Find the GDB manual and other documentation resources
> online
> > >>>>>
> > >>>>> at:
> > >>>>> > > > > <http://www.gnu.org/software/gdb/documentation/>.
> > >>>>> > > > > For help, type "help".
> > >>>>> > > > > Type "apropos word" to search for commands related to
> "word".
> > >>>>> > > > > Signal        Stop Print Pass to program Description
> > >>>>> > > > > SIG32         No No Yes Real-time event 32
> > >>>>> > > > > Signal        Stop Print Pass to program Description
> > >>>>> > > > > SIG41         No No Yes Real-time event 41
> > >>>>> > > > > Signal        Stop Print Pass to program Description
> > >>>>> > > > > SIG42         No No Yes Real-time event 42
> > >>>>> > > > > Signal        Stop Print Pass to program Description
> > >>>>> > > > > SIG43         No No Yes Real-time event 43
> > >>>>> > > > > [Thread debugging using libthread_db enabled]
> > >>>>> > > > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > >>>>> > > > >
> > >>>>> > > > > ---- my program output ---
> > >>>>> > > > >
> > >>>>> > > > > Breakpoint 1,
> footprinter::create_split_segments<...templates,
> > >>>>> > >
> > >>>>> > > templates,
> > >>>>> > >
> > >>>>> > > > > templates...>../footprinter.hpp:146
> > >>>>> > > > > 146    vector<segment_data<double>> segments;
> > >>>>> > > > >
> > >>>>> > > > >
> > >>>>> > > > > Cheers.
> > >>>>> > > > >
> > >>>>> > > > > Jeremy
> > >>>>> > > > >
> > >>>>> > > > >
> > >>>>> > > > > On 26 July 2016 at 16:02, Jeremy Murphy <
> > >>>>> > >
> > >>>>> > > jeremy.william.murphy at gmail.com>
> > >>>>> > >
> > >>>>> > > > > wrote:
> > >>>>> > > > >> Hi everyone,
> > >>>>> > > > >>
> > >>>>> > > > >> I'm loving KDevelop 5.0 alpha/beta/gamma whatever it is up
> > >>>>>
> > >>>>> to.  :)
> > >>>>>
> > >>>>> > > > >> Except recently, it started sending verbose GDB output to
> the
> > >>>>>
> > >>>>> Debug
> > >>>>>
> > >>>>> > > view
> > >>>>> > >
> > >>>>> > > > >> (along with the actual program output that I would expect)
> > >>>>>
> > >>>>> like so:
> > >>>>> > > > >> (gdb) 1-gdb-show version
> > >>>>> > > > >> GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1
> > >>>>> > > > >> Copyright (C) 2016 Free Software Foundation, Inc.
> > >>>>> > > > >> License GPLv3+: GNU GPL version 3 or later <
> > >>>>> > > > >> http://gnu.org/licenses/gpl.html>
> > >>>>> > > > >> This is free software: you are free to change and
> > >>>>>
> > >>>>> redistribute it.
> > >>>>>
> > >>>>> > > > >> There is NO WARRANTY, to the extent permitted by law.
> Type
> > >>>>>
> > >>>>> "show
> > >>>>>
> > >>>>> > > > >> copying"
> > >>>>> > > > >> and "show warranty" for details.
> > >>>>> > > > >> This GDB was configured as "x86_64-pc-linux-gnu".
> > >>>>> > > > >> Type "show configuration" for configuration details.
> > >>>>> > > > >> For bug reporting instructions, please see:
> > >>>>> > > > >> <https://bugs.gentoo.org/>.
> > >>>>> > > > >> Find the GDB manual and other documentation resources
> online
> > >>>>>
> > >>>>> at:
> > >>>>> > > > >> <http://www.gnu.org/software/gdb/documentation/>.
> > >>>>> > > > >> For help, type "help".
> > >>>>> > > > >> Type "apropos word" to search for commands related to
> "word".
> > >>>>> > > > >> 1^done
> > >>>>> > > > >> (gdb) 2-gdb-set width 0
> > >>>>> > > > >> 2^done
> > >>>>> > > > >>
> > >>>>> > > > >> ---8<--- ~200 lines of output ---8<---
> > >>>>> > > > >>
> > >>>>> > > > >> (gdb) 129-var-create --thread 1 --frame 0 var113 @
> "typename"
> > >>>>> > > > >> 129^error,msg="-var-create: unable to create variable
> object"
> > >>>>> > > > >> (gdb) 130-var-create --thread 1 --frame 0 var114 @
> > >>>>>
> > >>>>> "back_inserter"
> > >>>>>
> > >>>>> > > > >> 130^error,msg="-var-create: unable to create variable
> object"
> > >>>>> > > > >>
> > >>>>> > > > >>
> > >>>>> > > > >> It sends the messages when I run debug, obviously, but
> also
> > >>>>>
> > >>>>> when I
> > >>>>>
> > >>>>> > > mouse
> > >>>>> > >
> > >>>>> > > > >> over variables as the last couple of lines are an example
> of.
> > >>>>> > > > >>
> > >>>>> > > > >> I'm using the latest releases of just about everything,
> which
> > >>>>>
> > >>>>> at the
> > >>>>>
> > >>>>> > > > >> moment is GDB 7.11.1, Qt 5.6.1, Frameworks 5.24.0, Plasma
> > >>>>>
> > >>>>> 5.7.2, and
> > >>>>>
> > >>>>> > > tip
> > >>>>> > >
> > >>>>> > > > >> of
> > >>>>> > > > >> the 5.0 branch for KDevelop and KDevPlatform.
> > >>>>> > > > >>
> > >>>>> > > > >> Is this a known issue or am I the lucky discoverer? I
> can't
> > >>>>>
> > >>>>> recall
> > >>>>>
> > >>>>> > > > >> exactly when I first noticed it, sorry, but it must have
> been
> > >>>>> > >
> > >>>>> > > recently.
> > >>>>> > >
> > >>>>> > > > >> Thanks, cheers.
> > >>>>> > > > >>
> > >>>>> > > > >> Jeremy
> > >>>>> > > > >
> > >>>>> > > > > _______________________________________________
> > >>>>> > > > > KDevelop-devel mailing list
> > >>>>> > > > > KDevelop-devel at kde.org
> > >>>>> > > > > https://mail.kde.org/mailman/listinfo/kdevelop-devel
> > >>>>> > >
> > >>>>> > > --
> > >>>>> > > Kevin Funk | kfunk at kde.org | http://kfunk.org
> > >>>>>
> > >>>>> --
> > >>>>> Kevin Funk | kfunk at kde.org | http://kfunk.org
>
>
> --
> Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160820/db3968e8/attachment-0001.html>


More information about the KDevelop-devel mailing list