Bug 318635 - Crash assistant wizard - enter crash description before generating backtrace
Summary: Crash assistant wizard - enter crash description before generating backtrace
Status: RESOLVED WORKSFORME
Alias: None
Product: drkonqi
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2013-04-20 13:14 UTC by GDR!
Modified: 2018-10-27 02:53 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description GDR! 2013-04-20 13:14:14 UTC
I want to help the KDE community by submitting the crashes that occasionally happen on my system. In these cases, a bug wizard starts, asks me if I remember what I was doing prior to the crash - of course I did - then for half an hour up to several hours generates crash dump data, and after all this makes me type in the details about what happened. I don't remember any details, I've moved on since then. This is not logical. This makes me report about 1/10th bugs I encounter.

Long story short:
1. Ask user if he knows what he did before crash
2. Let the user type what he did before crash
3. Start the lengthy backtrace generation process

Reproducible: Always

Steps to Reproduce:
1. ((void*)0) = 0
2. Fill out a bug report
3.
Actual Results:  
You forgot what you were doing 3 hours ago, when the crash happened

Expected Results:  
You remember what happened, because it was seconds ago
Comment 1 Christoph Feck 2013-04-20 22:24:47 UTC
On the other hand it does not make sense to enter the description, if the bug can later not be reported because the backtrace lacked the required debug symbols.
Comment 2 Jekyll Wu 2013-04-21 20:07:42 UTC
>  then for half an hour up to several hours generates crash dump data

Are those numbers real or exaggeration ?  If real then is your harware very old ? It never takes more than 2 minutes in my 5 years old laptop to generate the backtrace. If your hardware is not that old, you should better check your system. Whatever, it is gdb, with the request from drkonqi, that does the real work of generating backtrace. 

Or maybe those numbers include the downloading time of debug symbols ? 

Now back to the suggestion itself. There is good reason to generate backtrace early. You know, not every crash is valuable enough for reporting. Even if your system has all debug symbols available, sometimes strange crashes just happen and gdb just can't get useful backtrace. Drkonqi will refuse to report those kind of crashes, because they unfortunately can't provide useful information to developers. 

Now if drkonqi first asks users to try their best to desribe the problem, then gnerate the backtrace, and in the end tell them "the backtrace is useless so we won't accept your report", how will those users, who have spend valuable time in describing the crash in detail, feel about DrKonqi ?
Comment 3 GDR! 2013-04-22 06:42:08 UTC
No, these numbers are not an exaggeration. There is often need for downloading more debug symbols, but my internet is rather fast (60 Mbit/s down) so it still shouldn't take that amount of time.

Even when not downloading any -dbg packages, it takes a very long time. I have two KDE machnies, an EEE PC 1005px and a 4-core $GB RAM SSD desktop. I've used kubuntu and mint over the years and it was consistently slow. My experience with crash assistant has been the same on both machines. I don't have any unusual settings.

It's a good point that generating the backtrace in the end makes sense if the backtrace is a duplicate. I don't know what to do then, because it really discourages me (and probably thousands of other users) from sending automated bug reports.
Comment 4 Jekyll Wu 2013-04-24 14:31:33 UTC
> > I've used kubuntu and mint over the years and it was consistently slow

There are two possibilitites I can think of  : 

1. gdb itself is very slow in generating the backtrace. Not drkonqi's problem.

2. gdb itself finishes its job quickly (within 2 minutes, as it should ), yet drkonqi somehow fails to notice that and still waits for it. DrKonqi's fault.

It is not hard to identify which case is happening in your system:  suppose it usually takes 30mins for the backtrace to become available, then use 'ps' or 'ksysguard'
to check whether the gdb process is still running at minute 5, 10 ,15, etc.  If gdb is still running at those points, then it is gdb's fault.
Comment 5 Jekyll Wu 2013-05-19 07:15:35 UTC
see comment #4
Comment 6 Richard Llom 2013-05-27 15:12:33 UTC
(In reply to comment #2)
> >  then for half an hour up to several hours generates crash dump data
> 
> Are those numbers real or exaggeration ?  If real then is your harware very
> old ? It never takes more than 2 minutes in my 5 years old laptop to
> generate the backtrace.
> 
My laptop is also about 5 years old (or maybe a little more, its "Intel(R) Pentium(R) Dual  CPU  T2330  @ 1.60GHz") and I can remember of backtrace generation of about 30min, but nothing more than 1 hour. But most of the time I think its more around 5 mins.
Comment 7 Christoph Feck 2013-06-13 21:30:12 UTC
If you get a crash next time, could you please use Ctrl+Esc to check if the process "gdb" runs during the complete 5 (or more) minutes?
Comment 8 Andrew Crouthamel 2018-09-24 02:02:51 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Andrew Crouthamel 2018-10-27 02:53:33 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!