Description of problem: Lately abrt has started to insert backtraces as text rather than adding them as attachments. While text might be suitable for comments, the event log or environment variables, it is IHMO bad for backtraces because reading or comparing them in order to find duplicates has become quite hard. Backtraces should not be re-formated, the output should be exactly as from gdb in order to provide consistency. Version-Release number of selected component (if applicable): abrt-2.0.2-5.fc15
Try to read and compate these two backtraces: attachment.cgi 492594 bug 712893 comment 0 The latter is very hard do read, you can hardly see where new functions are starting because so many lines have linebreaks.
*** Bug 712716 has been marked as a duplicate of this bug. ***
Well, there was a request from other group of developers to have backtrace as comment, so it's searchable. I think the solution here is to teach bz to search even in text/plain attachments and then everyone will be happy with backtrace as attachments.
Bugzilla can already search attachments: Advanced Searching Using Boolean Charts -> Attachment data: contains: <search term> So the solution is to teach developers how to use bugzilla. ;) Once we have done that, can we switch back to attachments?
Keeping this Bug open in fact makes it CANTFIX no matter what the intention is. The Bugzilla is already getting polluted so that one already needs to exclude ABRT Bugs by "Advanced Searching Using Boolean Charts" during any search.
(In reply to comment #5) > Keeping this Bug open in fact makes it CANTFIX no matter what the intention is. Does this mean we'll never get back to attachments? Jiri, what is your opinion here? *If* we stick with inline backtraces, we should at least remove the traling : and have bugzilla treat backtraces better. See GNOME's bugzilla for a nice way to handle that. > The Bugzilla is already getting polluted so that one already needs to exclude > ABRT Bugs by "Advanced Searching Using Boolean Charts" during any search. One more reason to stick with attachments....
Yes, the bt are going back to attachments and the limit for inline backtraces(and others) will be lowered, but even when the bt is inlined it will be added as attachment for easier processing.
I am confused now: Sometimes I get attachments, sometimes I get backtraces inline, even with F16. What is the pattern here?
(In reply to comment #8) > I am confused now: Sometimes I get attachments, sometimes I get backtraces > inline, even with F16. What is the pattern here? - in older ABRT there is a threshold when bt is uploaded attachment and not inlined, the new version will attach the backtrace as attachment everytime + inline it only if it's really short (which is usually case of python traces) - does it sound reasonable or did you have different idea?
Yes, sounds reasonable, for python backtraces inline is fine. Thanks!
(In reply to comment #9) > inline it only if it's really short (which is usually case of python traces) Seems the limit is to high. I consider the backtrace from bug 747576 not really as short.
The limit has been lowered to 2kb (25 lines * 80 chars), this change will be included in next update. Fixed in git (commit: ef8e805f506979bca17c7c5ec24c3468d012ea97)
I can't grep my bug mail folder for backtraces any more, and have to resort to the (slow) bugzilla search (if I'm even online at all). kernel backtraces are frequently longer than 25 lines, so this check is going to be irrelevant for us. I can see why Christoph complained about that enormous comment, but it seems the problem here is that there's so much irrelevant junk in there under 'backtrace' that isn't actually a backtrace at all. It seems a better solution to this bug would be to not file a whole bunch of that stuff at all. The list of PCI devices is totally irrelevant. The list of mounts. Environment variables. etc. etc. What creates all that spew ? Because it seems to me *that* is what needs fixing.
IMO, what needs fixing is searching in bugzilla, because a bug mail folder won't help you much for bugs which are assigned/CCed to you only after the backtrace is added (e.g. on change of components, not that uncommon with abrt-generated tickets). Besides that, backtraces as inline comments are often hard to read because of wrapping lines.
if we can't reach consensus on this issue, please at least consider adding a special case for the kernel component to have traces as comments.
I will move limit up to 4 or 5kB.
As Nikola said we will raise the limit for inline attachments and make everything which is not backtrace into attachments so it doesn't pollute the initial comment.
abrt-2.0.7-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/abrt-2.0.7-2.fc16
Package abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.7-2.fc16 libreport-2.0.8-3.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16990/libreport-2.0.8-3.fc16,abrt-2.0.7-2.fc16 then log in and leave karma (feedback).
abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
This is still inadequate. See bug 772247 for example. Please either come up with a better solution for this, or special case the kernel out of backtrace-as-attachment.
(In reply to comment #21) > This is still inadequate. See bug 772247 for example. > > Please either come up with a better solution for this, or special case the > kernel out of backtrace-as-attachment. Yes, please.
commit ef2010f68eb10e8972d02e428d3c2d52206e729e Author: Nikola Pajkovsky <npajkovs> Date: Wed Jan 11 09:48:42 2012 +0100 rhbz#712602 - inline always kernel bt Signed-off-by: Nikola Pajkovsky <npajkovs>
abrt-2.0.9-1.fc17, libreport-2.0.10-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/abrt-2.0.9-1.fc17,libreport-2.0.10-1.fc17
Package abrt-2.0.9-1.fc17, libreport-2.0.10-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.9-1.fc17 libreport-2.0.10-1.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4804/abrt-2.0.9-1.fc17,libreport-2.0.10-1.fc17 then log in and leave karma (feedback).
abrt-2.0.10-1.fc17,libreport-2.0.10-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/abrt-2.0.10-1.fc17,libreport-2.0.10-2.fc17
abrt-2.0.10-1.fc17, libreport-2.0.10-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.