Bug 319886

Summary:	Lower Process and I/O Priority for debugging / backtrace generation
Product:	[Applications] drkonqi	Reporter:	Richard Llom <richard.llom>
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	adaptee, mail, sitter
Priority:	NOR
Version:	2.1.5
Target Milestone:	---
Platform:	Chakra
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Richard Llom 2013-05-15 21:43:58 UTC

Sometimes I encounter crashes in KDE software during productive work time. Nevertheless I often still (like to) take the time to report the crash.
While the clicking through the steps is relative fast, the generation of the backtrace can consume quite some time AND WORST it uses all CPU to 100%. So it is NOT possible to click "Generate backtrace" switch to work application, continue work and then after a while switch back to drkonqi, with the finished backtrace.

Thats why I propose to lower the process and I/O priority for debugging / backtrace generation in drkonqi, so that it runs in the background, i.e. it is possible to work lagfree in other applications at the same time.

Comment 1 Jekyll Wu 2013-05-19 07:15:19 UTC

There is a quick trick :

  1. open /usr/share/apps/drkonqi/debuggers/internal/gdbrc
  2. change the line :

        "Exec=gdb -nw -n -batch -x %tempfile -p %pid %execpath"

     into 

        "Exec=nice gdb -nw -n -batch -x %tempfile -p %pid %execpath"


However, I personally never have the feeling that drkonqi(actually, it is gdb) is taking too much time or too much CPU resource to generate the backtrace that it influences my normal workflow. So I can't say whether that trick will bring noticeable change. 

Also, someone reports drkonqi (again, it is actually gdb) takes too long time to generate the backtrace. If we make drkonqi(gdb) nicer, it will takes even longer time for that user. See bug 318635.

Comment 2 Richard Llom 2013-05-27 14:24:35 UTC

(In reply to comment #1)
> There is a quick trick :
> ...
Well, this looks nicer, although I could test now with only a small backtrace.

>, I personally never have the feeling that drkonqi(actually, it is
> gdb) is taking too much time or too much CPU resource to generate the
> backtrace that it influences my normal workflow. So I can't say whether that
> trick will bring noticeable change.
Here on my notebook I have "only" two cores and gdb uses both to the max -> can't do anything else.

> Also, someone reports drkonqi (again, it is actually gdb) takes too long
> time to generate the backtrace. If we make drkonqi(gdb) nicer, it will takes
> even longer time for that user. See bug 318635.
Not necessarily, only when there are actually other programs are running and using cpu time.

Comment 3 Harald Sitter 2019-07-02 14:02:09 UTC

As Jekyll said, if we make it nicer it'd take longer which is in fact counter productive since drkonqi is an interactive dialog. If it was tracing in background niceness would make sense, seeing that is not the case it really doesn't make sense to reduce its priority. If desired a user can edit gdbrc as demonstrated.