| 2007-03-22 16:55:46 |
Matthias Klose |
bug |
|
|
added bug |
| 2007-03-22 19:01:58 |
Martin Pitt |
apport: status |
Unconfirmed |
Needs Info |
|
| 2007-03-22 19:01:58 |
Martin Pitt |
apport: statusexplanation |
|
> - 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? |
|
| 2007-07-06 11:24:26 |
Martin Pitt |
apport: status |
Incomplete |
Invalid |
|
| 2007-07-06 11:24:26 |
Martin Pitt |
apport: statusexplanation |
> - 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? |
We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future. |
|
| 2007-07-06 12:48:02 |
Matthias Klose |
apport: status |
Invalid |
New |
|
| 2007-07-06 12:48:02 |
Matthias Klose |
apport: statusexplanation |
We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future. |
reopening. closing as "invalid" sounds wrong; if you don't have a better idea then having a mapping of exceptions to error types, and if that will not be implemented for some reason, then please close as "wontfix". |
|
| 2007-07-24 12:22:10 |
Martin Pitt |
apport: status |
New |
Won't Fix |
|
| 2007-07-24 12:22:10 |
Martin Pitt |
apport: statusexplanation |
reopening. closing as "invalid" sounds wrong; if you don't have a better idea then having a mapping of exceptions to error types, and if that will not be implemented for some reason, then please close as "wontfix". |
It is not possible to generally determine whether an exception is a program bug or an user error, and the majority of unhandled exceptions are actual bugs. If programs really want to ignore certain exceptions for themselves, they could ship an apport hook, but preferably they should just be fixed to give a proper error message to the user. |
|
