Caolan McNamara wrote:
So when OOo crashes, what are the strategies that distros employ here if
any ?
Sun has a SOAP receiving service for crash reports, a database to store
crashreports, a daemon service which tries to find similiar stacktrace
based on the information send in the XML file which works with a certain
fuzziness, a web frontend for development to look at the stuff stored in
the database and some automated process which generates tasks from crash
reports to developers in a Sun internal bugtracking system based on
frequency of crashes. The autosubmission of tasks and the web frontend
provide some means to resolve the data send with the crash report
against the debug information kept for released versions using platform
depend utilities, eg. kd.exe on windows addr2line on unix. The
autosubmission of tasks merly guesses on a potential developer which
could become the possible first owner based on applying random function
to the library owners of the first 5 stackframes, mostly such tasks get
reassigned by the first owner to a better one sometimes the one
initially getting the Task is already the right one. In the database
reports have their own reportid and similar ones are grouped together
under a common stackmatchid.
For RH we don't build the crashreporter (as it's basically unusable info
for Sun),
This is because Sun would not have the debug information created during
building those Releases which would be needed to 'resolv' the crash
report getting stackinformation with source code filenames, classes and
line numbers out of it. The information in the XML file is not enough
for the developer to locate the origin of the problem, it´s only enough
for checking possible similiarity.
but we do configure to enable using it, and replace it in the
install set with a simple replacement that tests for the set of common
problems that historically caused crashes, e.g. nvidia drivers, a11y
enabled, selinux settings and insane local library butchering, and
prompts the unfortunate user to log the supplied text to the RH
bugzilla, and we map the stack back to source with
http://people.redhat.com/caolanm/ooocvs/ooomapstack after throwing out
the nvidia driver using reports
This ooomapstack utility most likely will also need access to debug
information kept during the build, wouldn´t it?
At some stage in the past the ooobuild OOo would spawn off the gnome
gnome bug-buddy, but that's no longer the case is it ?
So do other distros have various solutions here, or just simply crash
out and/or dump core ?
What I'm thinking about aiming at is a shared cross-distro crash
repository where we can auto submit the distro OOo crashes, and the
distros can plug in their various stack mappers, with quick and dirty
gnomebugzilla-alike tooling to merge the duped backtraces together.
I see a few potential problems with that:
1.) Crash data does contain dump of memmory which in some cases might
contain personal information which end-users would not want others to be
able to find on public websites. There is stuff like
http://www.sun.com/privacy/ and I am quite sure others do have similar
terms to adhere to. Which means that anything we can create can not be
created in full public but must have limited access to restricted
group(s) of developers who agree on common terms of handling possible
private data in a secure manner.
2.) Who should host this repository? Or are you thinking about some kind
of distributed or partly distributed repository?
3.) Resources have to be available to call something like RH´s
ooomapstack utility or Sun´s crashdebug utility on all supported platforms.
4.) Resources have to be available to keep debug information for all
builds for doing 3.)
5.) 3.) + 4.) have to be on the same network meaning that either one
contributor would have to provide disk space and computing resources for
anyone else or that everyone has too keep it´s one debug-information and
provide computing resources for the community to 'resolv' crash reports
send in for their distributions.
6.) At least what we (Sun) currently use as 'StackMapping' (in terms of
grouping together similar reports) does often have false mapping in both
directions, that means that the system sometimes things 2 reports are
similiar but the developer later on finds out that they have a differnt
root cause and that also the system sometimes thinks two reports are not
similar but the developer later on finds out that they do in fact have
the same root cause. Considering our 'fuzzy'-algorithm that´s where I am
starting to wonder how that gnomebugzilla-alike tooling to merge the
duped backtraces together might look like! Handling does false positives
/ false negatives already has become a time consuming task which would
get worse with a larger repository containing data for all distros.
7.) With the amount of data that we (Sun) currently already have in the
database stackmatching already has become a resource hog. In a
distributed system which keeps information for ALL distributions it
would be even more complicated and time consuming to find matches. This
can soon get over the limit of where the matching service(s) can only
handle X incoming reports per hour and we will in fact get Y incoming
reports per hour with Y>X. We already nearly had such situation in the
past resulting in various new implementations of matching algorithm and
database design.
8.) I don´t understand the approach of everyone plugging in an own
stackmapper. Why would distro-A use Algorithm-A for guessing similarity
while distro-B would use Algorithm-B and how would than the overall
quality of things matched into the same stackmatchid look like regarding
false positives / false negatives? Or wait you did not talk about
grouping of reports together as one stackid but about resolving them
with something like RH's ooomapstack or Sun's crashdebug utility. Than
well yes, see 5) and we would need to have at least a common interface
eg. somewhere on a web application service for being able to call that
crash 'resolving' for any developer who got the access rights to analyse
crash reports.
>
> C.
>
Kind regards,
Bernd Eilers
Maintainer of Sun´s report handling backend infrastructure services and
corresponding developer web application.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
