Debug view receives verbose GDB messages
Jeremy Murphy
jeremy.william.murphy at gmail.com
Tue Aug 16 11:38:02 UTC 2016
I can confirm that it is fixed on the 5.0 branch now. Thanks!
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
>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160816/d67c24f1/attachment-0001.html>
More information about the KDevelop-devel
mailing list