On Fri, 2007-05-18 at 15:43 +0200, Bernd Eilers wrote: > 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,
I'm aware of the tooling there, but this is somewhat orthogonal as the Sun tooling is internal and doesn't factor into this much. > > 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 But we do of course, and are both able to and actually do the mapping. And probably other distros can as well, and actually any of the distros using debuginfo rpms can use the simple RH ooomapstack tooling without much modification I'd assume. > This ooomapstack utility most likely will also need access to debug > information kept during the build, wouldn´t it? Yup, not a problem. We keep that info around for all our packages e.g. for the latest Fedora Core 6 it just needs an unpacked http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/debug/openoffice.org-debuginfo-2.0.4-5.5.22.i386.rpm so any potential cross-distro crash server would just need a little fedora core disto specific plugin to go fetch the matching debuginfo rpm and run ooomapstack on it. > 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. All that's at stack here is the basic simple stack traces, without memory dumps. So the issue doesn't arise. > 2.) Who should host this repository? Or are you thinking about some kind > of distributed or partly distributed repository? Well, that's the nub of the issue isn't it. But I don't see this as affecting Sun in any way, i.e. this isn't intended as pumping more data into Suns database, just an alternative crash reporter for the distro builders that might point at a shared database. Certainly there may be issues of scalability and it may be impractical. I was thinking of whipping something Red Hat specific together and giving it a whirl during the up and coming development cycle when there are a limited number of users to get a feel for how much data and server load would be involved when not considering vast number of window users and where all traces would generally come from a very homogeneous environment. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
