Hi, I'm wondering if ABRT is still actively-developed since one of the main developers left Red Hat recently. I have a few complaints that have been annoying me for some time: (1) ABRT is frankly very bad at detecting whether bugs are duplicates of each other. It keeps telling users that their bugs are duplicates of completely and totally unrelated bugs. The only commonality is that a *non-crashing* thread in the backtrace is blocked in pthread_cond_wait, which is almost always the case in WebKit crashes, for example. I guess this is just a bug, and ABRT is failing to detect the crashing thread properly. I've mentioned a few cases in https://bugzilla.redhat.com/sho w_bug.cgi?id=1396475, but there are really dozens of these that I haven't bothered to mention there. Users keep marking their bugs as duplicates of unrelated bugs, because ABRT tells them that the bugs are duplicates, which makes it harder to manage bugs and is getting *very* annoying. Most recent case of this is https://bugzilla.redhat.com/show_ bug.cgi?id=1426813, but I'm sure there have been two or three more in the past week. (2) I don't want to ever receive any private bug reports, since all I do is forward them to public upstream Bugzilla. The reasonable options are (a) ignore the bug report, since it cannot be forwarded, or (b) make it public. I always use (b), except in the extremely unusual cases where the bug report really does contain some obvious sensitive data (like a URL) and I happen to notice it, in which case I'll ask the reporter. My point is the private bug report feature is useless if the reports are either going to be ignored or set public anyway. This was not previously much of a problem because bug reports were always public by default, so not many people used them. But nowadays, bug reports are almost always private by default, due to (3). (3) The heuristic that guesses whether a bug report contains sensitive data is terrible. If the word "key" is present in the backtrace, ABRT decides that bugs should be private by default. But "key" is always going to be in your backtrace if your application uses hash tables. I've filed dozens, maybe hundreds, of ABRT reports, and am genuinely uncertain if I've ever seen either (a) ABRT not flag sensitive data in a backtrace I was going to upload (it almost always flags "key"), or (b) a backtrace I was going to upload that actually contains sensitive data. 99% of the time it is just false positives, so I always ignore ABRT's sensitive data warnings. I think simply not matching on "key" would help a lot here. Otherwise, the entire sensitive info warning is basically useless due to the false positives. Michael _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
