Description of problem: Currently abrt seem to just decide which component to file a bug against based on the binary that crashed. But in many cases the crash can be caused by library that said binary was linked against; which is clearly visible in the backtrace. abrt should be smart enough to file the bug against the correct component and save the maintainers/triagers a lot of time they spend on reassigning bugs.
*** Bug 603290 has been marked as a duplicate of this bug. ***
*** Bug 603288 has been marked as a duplicate of this bug. ***
Hi, finding the library where the crash happen shouldn't be difficult, but the problem is how could we determine if the crash is really caused by bug in a library or by the application which is using the library in a wrong way? J.
The reverse could also happen: a library returns a corrupt pointer which the application dereferences, and the application is blamed. I don't think there's any way to automatically determine fault. The decision of whether ABRT should file crashes in library code against those libraries should be based on the empirical percentage of such crashes that are in fact the fault of the libraries.
Since there's no systematic way of figuring out if it's the app or the library, perhaps abrt should file the the bug against both? I don't think Bugzilla allows specifying two components for the same bug so it would have to be two separate bugs, which sounds heavy-handed. Two mitigating circumstances are: - abrt would only do it if the stack trace clearly indicates that a library is involved - bug reviewers can quickly close the superfluous one
(In reply to comment #5) > Since there's no systematic way of figuring out if it's the app or the > library, perhaps abrt should file the the bug against both? For whatever is holy and worthy to you, NO!!! We have already too many duplicates and we don't want intentional duplicates of duplicate bugs. If you think there are too few bugs in bugzilla, you can go and help me to get in order https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=all%20NEW%20abrt%20crashes&sharer_id=74116 ;) The only reasonable solution for crash collection IMHO is to move all this database outside of bugzilla. I really believe that something in the tune of crash-stats.mozilla.org is much better way to go (all crash are dumped into another database somewhere else, and only from there new bugs are created by maintainer (or bug triager)).
I take your point that we're overwhelmed with the torrent of auto-generated bugs. I think it's the classic example of a 'pets vs. cattle' shift: something, like i.e. desktop computers, that traditionally was treated as 'pets', dramatically increased in volume and should be treated as 'cattle' instead. In this specific case, we used to see crashes as individual bugs-to-be-fixed, but we also need to have a high-altitude, large-statistics view of where the problems are. You are saying that we need something like crash-stats ('crashzilla'?) as a separate system that feeds bugzilla. I am trying to see a way to do adapt bugzilla to do it. Perhaps introduce a new STATUS 'CRASH-REPORT' that doesn't count as a full-fledged bug? Then, it would be just like crash-stats: competent people would classify and group reports, and change the status to 'NEW'. I don't know if bugzilla infrastructure can sustain the volume implied by such usage pattern. By the way, I got the error message "The search named all NEW abrt crashes has not been made visible to you" when I tried your suggestion https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=all%20NEW%20abrt%20crashes&sharer_id=74116 Shall I file a bug on this :)?
(In reply to comment #7) > You are saying that we need something like crash-stats ('crashzilla'?) as a > separate system that feeds bugzilla. That isn't what I was saying ... s/that feeds bugzilla/which is source of data for human to file bugs/ The point is that only humans are worthy to file bugs in bugzilla. > By the way, I got the error message "The search named all NEW abrt crashes has > not been made visible to you" when I tried your suggestion > https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=all%20NEW%20abrt%20crashes&sharer_id=74116 > > Shall I file a bug on this :)? It's probably open only to bugzappers.
(In reply to comment #7) >> You are saying that we need something like crash-stats ('crashzilla'?) as a >> separate system that feeds bugzilla. > That isn't what I was saying ... > s/that feeds bugzilla/which is source of data for human to file bugs/ I am arguing that if there was a way for you to NOT see the automatic bug reports unless you ask for them, bugzilla would functionally behave the way you want. There might be an integration advantage to having all the reports (manual and automatic) in the same system---e.g. easier to link them together. Or, it may be too hard to modify bugzilla in the way I propose, and it'd be easier to create a separate database for automatic bugs---that could still be linked to from your bugzilla. Again, my point is that it does not _have_ to be a separate system; it's an implementation issue
I start more and more to think an crash-database would be a nice way to go. This should store all crashes and then be linked to bugzilla-reports. That crash-database could also store information like: * what components were directly involved in the crash, and what versions they were (if abrt finds one application and one library in the backtrace it could store both versions) * what versions it has been reproduced with (currently if someone makes a crash with version 1.0-1 and there was a 1.0-2 released that should fix the crash and someone gets the same crash with that package, the bug can in the current system still be closed if the original reporter never goes back to the bug and provides a needinfo even when someone other has the information) * more then one backtrace unless they are exactly identical (there are bugs where the original reporter for some reason never had debuginfo installed for one or more packages and the backtrace is incomplete, but because of this the only backtrace in the bugreport is broken with a 50+ "mee too"s after) * easier bug-report-parsing (the bugreport of common issues does not just become a long list of abrt generated "mee too"s like bug #606615) * linking between bugzilla-reports and crash-stat (makes it possible to change all kind of information in the bug itself like component without confusing abrt since the information abrt queries lives in the crash stat and is independent of the infromation living in bugzilla. This could also allow to link more then one bug report per crash, if the problem maybe calls for more then one fix or spawns over more then one component/package) * allow storing of information even after a bug is closed, maybe filtered on if the crash has been reproduced with the current installed version of the responsible package (I have hit bugs I have had to "manually" report since the bug already existed, but was closed against a earlier version of the package then I was using, and I had to manually comment in the bugreport that it had reappered since abrt refuses to send comments to that closed bug, probably because abrt has no way to query if the issue was reported against the version I had installed without trying to parse all comments in the bug) I think the crash-database-entry could be more of a "tracker" for every crash where all information that may be needed is stored, and this without "bloating" the bugzilla-database. Then it could be integrated by bots into the bugzilla, so bots may for example query the crash-database if a problem exists in later versions of fedora before it closes a bug because the fedora version the bug was reported against reaches EOL, or maybe even update the bugreport depending on events (like reproduction done in a for the crash-database new version of the package/packages). The crash-database itself could have a web-interface whith a button "report this crash to bugzilla", and maybe rigged so it triggers a automatic bugreport when a threshold of reproductions has been made. This if there is no bugreport linked to the crash already. Much of this could be implemented to be stored in the bugzilla-database having bugzilla as a common interface, but the question is if it really is practical any more to handle automatic crash reports as bug, or if they should be seperated both logical and "physical", and the crash only looked upon as a symptom of a bug rather than a bug in itself.
Karl Vogel has an interesting discussion relevant to the bugzilla growth and management issues from the 'abrt' debate. The blog is titled "Bug Growth is Proportional to User Growth, and Bugs are not Technical Debt": http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/ He makes a point that for a growing project it doesn't even make sense to expect zero or constant bugs---instead, the challenge is how to manage the infinite growth. I think Peter Hjalmarsen's (comment #10) has good ideas on how to deal with this.
This problem should be handled (at the summary) by the new service: https://fedorahosted.org/faf/milestone/Backtrace%20deduplication%20server which should be available in spring 2012.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
ABRT doesn't report to Bugzilla in default configuration anymore. We use dedicated servers for bug reporting. Closing.