apport sends bug reports for situations which are not bugs
Bug #94822 reported by
Matthias Klose
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apport (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: apport
see bug 89547:
- it is a simple python backtrace. why is it necessary to send Procmaps
and Procstatus? IMO it's only misleading. Are there siturations, where
this information has any value? If not, please don't add it.
- the problem type is labeled "Crash", although the exception is
OperationalError. If you think that crash reports are necessary
for unhandled interpreter exceptions, then please analyze the
exception and only file a report for error conditions. Wrong bug
reports are not better than a probably missing report.
To post a comment you must log in.
> - it is a simple python backtrace. why is it necessary to send Procmaps
> and Procstatus? IMO it's only misleading. Are there siturations, where
> this information has any value? If not, please don't add it.
They are very important for crashes of binary programs, and they will teach the triager about custom libraries, special plugins, etc. It's cheap, it does not need a lot of space, you can ignore it, so I'll just keep it.
> - the problem type is labeled "Crash", although the exception is
> OperationalError. If you think that crash reports are necessary
> for unhandled interpreter exceptions, then please analyze the
> exception and only file a report for error conditions. Wrong bug
> reports are not better than a probably missing report.
OperationalError is not a standard Python exception that we could generally ignore, and even in this case it is not clear to me whether this is a real program error (e. g. in this case it could be a failed macro expansion, or whatever) or an error from the user. However, usually programs should fail more gracefully than spitting an exception into the user's eyes.
How do you propose should this be analyzed merely by looking at the stack trace?