do not accept short crash reports for useless stack traces

Do you really need the crash dump or do you just want a debug backtrace for the problem reported? Martin, could apport try to detect if the backtrace has no useful function nor dump and warn the user than the bug has not enough details with a pointer on how to get them?

Indeed; I think it should be possible to use some heuristics to tell apart 'useful' from 'useless' stack traces (e. g. StacktraceTop just has unknown functions). In that case, we could just offer to upload the complete report.

Thanks,

Partial reports frustrate eveyone involved in firefox crashes. The reporter takes the time to upload about 10M of data. A triager goes through and finds that the report is missing data that we need to make a good retrace. Then the triager fires off a request to the original reporter asking for the full report.

Ideally we would like a full retrace (debug retace) from the reporter:) Since that is not practical, we would at least like all of the information necessary to run a retrace ourselves.

My first thought was to eliminate the option in the gui to send partial crash reports for certain packages, but your idea sounds better.

thanks
David

We just need a reasonable definition of what a 'usable' stack trace is. I guess it is best to look at StacktraceTop. The maximum we can expect is five function names (no arguments etc.), but that will only seldom be the case. From your experience, would 'at least 3 function names' be a reasonable first approximation?

3 function names should be enough, usually if the backtrace doesn't start with several "??" it's correct

There are valid situations where the most recent stack frame is unknown (for example, incorrectly attempting to execute stack or heap). Also there are times when the crash happens earlier, and various handlers are involved. Perhaps change it to 8 layers of "stacktop", and allow for it to be "valid" if at least 4 aren't "??"?

@Seb: what Kees said, that's why I didn't propose looking at only the top function. Independently from this, we should 'rewind' stuff after e. g. _raise() and other popular internal handlers from the StacktraceTop.

hum, my experience is that incorrect attempt to use the heap leads to the backtrace starting with a "??", the next function is usually correct (that's why I wrote "with several "??""), I'll ask to the GNOME bugzilla guys what they did for that, they also refuse bugs without a correct backtrace now

Fixed in bzr head.

 apport (0.78) gutsy; urgency=low
 .
   * apport/packaging.py, backends/packaging-dpkg.py: Add new interface
     is_distro_package(package) which verifies the origin of a given package.
     Move the dodgy hack from apport/ui.py to the backend, where it belongs to.
     Also add a test case.
   * debian/control: Add python-apt dependency to python-apport.
   * debian/control: Remove debianutils dependency, it's essential.
   * Drop backends/packaging-dpkg.py. It had some hackish usage of python-apt
     anyway, since some things just cannot be figured out with dpkg alone.
     Since we have to give up on that idea, implement a new clean packaging
     backend 'packaging-apt-dpkg.py' which now uses python-apt and dpkg in a
     clean way.
   * apport/report.py, add_gdb_info(): Fix crash when Stacktrace could not be
     created. (LP: #107853)
   * ./test-apport: Check that crashes create a core dump (with proper ulimits)
     when an unseen crash report exists already. This reproduces LP #105976.
   * bin/apport: Create core dump file if aborting because an unseen crash
     report already exists. (LP: #105976)
   * apport/ui.py: Add a comment for translators. (LP: #104703)
   * apport/ui.py, load_report(): Also catch zlib.error on invalid reports.
     (LP: #103547)
   * apport/report.py: Add method has_useful_stacktrace() to determine whether
     the stack trace can be considered useful. The current heuristic is to
     consider it useless if it either is shorter than three lines and has any
     unknown function, or for longer traces, a minority of known functions. Add
     test cases.
   * gtk/apport-gtk, qt4/apport-qt, cli/apport-cli: Do not offer 'reduced
     report' option if the stack trace is useless. (LP: #87430) Bump the
     python-apport dependencies of the frontend packages to ensure that we have
     has_useful_stacktrace().