Re: ABRT - Processing failed?
On 02/23/2013 12:04 PM, Michael Schwendt wrote: So, recently ABRT has started intercepting a few crashes but refusing to let me report them: /usr/bin/nm-applet Process /usr/bin/nm-applet was killed by signal 6 (SIGABRT) | Processing failed. | | --- Running report_uReport --- | Server side error: 'Validation failed: error validating 'installed_package': | missing mandatory element 'release'' | (exited with 1) What does that mean? For a second one from yesterday, also for nm-applet, it adds a detail, but also prints that strange server side error afterwards: | --- Running report_uReport --- | Generating backtrace | Cannot disassemble function at 0x0, not computing fingerprint | Server side error: 'Validation failed: error validating 'installed_package': | missing mandatory element 'release'' | (exited with 1) - it means that the report data doesn't contain 'installed_package' field - Updating to the latest abrt should help: abrt-2.1.1 libreport-2.1.1 btparser-0.25 F18: https://admin.fedoraproject.org/updates/FEDORA-2013-2111 F17: https://admin.fedoraproject.org/updates/FEDORA-2013-2124 --Jirka -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: ABRT - Processing failed?
On 02/25/2013 11:13 AM, Michael Schwendt wrote: On Mon, 25 Feb 2013 11:02:33 +0100, Jiri Moskovcak wrote: - it means that the report data doesn't contain 'installed_package' field - Updating to the latest abrt should help: abrt-2.1.1 libreport-2.1.1 btparser-0.25 F18: https://admin.fedoraproject.org/updates/FEDORA-2013-2111 F17: https://admin.fedoraproject.org/updates/FEDORA-2013-2124 How likely is it that the fix is incomplete? I'm running Rawhide and those packages are installed here for a longer time already: $ rpm -qi abrt libreport btparser|grep ^Ins Install Date: Fri 08 Feb 2013 09:14:47 PM CET Install Date: Fri 08 Feb 2013 09:14:45 PM CET Install Date: Sun 03 Feb 2013 02:42:28 PM CET $ rpm -q abrt libreport btparser abrt-2.1.1-1.fc19.x86_64 libreport-2.1.1-1.fc19.x86_64 btparser-0.25-1.fc19.x86_64 Last occurrence for the nm-applet crash is 2013-02-23. It's still listed in abrt-gui as not reported, and trying to report it still fails in the described way. Should I simply delete it? And when ABRT will catch it again, it would save report data including the 'installed_package' field? - deleting it should help - the original problem has been generated with older version with this bug and the installed_packages are missing and since all the consequent crashes are marked as duplicates and the content is not updated, so the installed_package is still missing --Jirka -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: abrt backtrace failures
On 05/23/2012 06:06 AM, Chuck Anderson wrote: During F17 RC testing, twice now [1][2] I've been unable to submit bugs using abrt because the backtrace was considered unusable by abrt. 1. Is there a problem with the debuginfo's or abrt functionality during this F17 final RC stage? 2. What happened to the Retrace Server? I don't see that option for F17, only Local GNU Debugger. This is caused by: https://bugzilla.redhat.com/show_bug.cgi?id=823812 You can just yum install abrt-retrace-client to get it back. 3. Can the abrt behavior be changed to allow the bug to be created, but perhaps without the bad backtrace, or perhaps marked in some way so it is known to have a bad backtrace? - right now ABRT uses a scale 1-4 to rate the backtrace and allows only 3 and 4 to be reported - we're thinking about adding a possibility to create the whole bug manually like in the web interface only it would be easier (using some kind of wizard probably) It is still helpful to the bug reporter to have abrt create the bug with as much info as possible, with the expectation that better/usable backtraces could be attached later manually if possible. - when ABRT finds a dupe in bugzilla it checks the quality of the attached backtrace and if the one being reported is better it attaches it - so this part is done - but on the other hand developer won't start working on a bug before he gets a good backtrace, so I think it's better to wait for a good one and then create the ticket rather than creating a ticket and waiting for a good backtrace - in that case the bug might go out of the developer's radar.. It is frustrating to be informed of a crash by abrt and go through all the effort to submit the bug report via abrt, only to be told sorry, I'm not going to let you submit this bug report because it doesn't meet our standards of quality. Frankly, it's a waste of the reporter's time and it conditions the user to not care to submit bugs in the future. - I totally agree, but please be patient. We're trying to make the whole process less painful. There are already few ongoing projects trying to deal with it like minidebuginfo and ABRT server (not the retrace server) Cheers, Jirka Thanks, Chuck [1] https://bugzilla.redhat.com/show_bug.cgi?id=823755 [2] https://bugzilla.redhat.com/show_bug.cgi?id=824228 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
New retrace-server is up'n'running
Hi, the new retrace server HW is finally set up and running. Since it has the same name as the old one (retrace.fedoraproject.org) no special configuration is needed, it *should* just work. pros: - support for F16 (so we can use it on liveCD (need to fix: 742609)) - support for rawhide (testers are welcome) - support for more parallel jobs (so hopefully no more Please try again later) - it's bigger, stronger, faster.. cons: - none (so far) Have a nice day, ABRT Team ps.: CCying awilliam in hope he will forward this message to test@lists.fedoraproject.org, because my last message didn't get through. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: colord core dump and abrt not reporting
On 05/14/2011 05:28 PM, Neal Becker wrote: May 14 11:23:24 nbecker1 abrt[17229]: saved core dump of pid 17226 (/usr/libexec/colord) to /var/spool/abrt/ccpp-2011-05-14-11:23:24-17226.new/coredump (18477056 bytes) But run abrt-gui doesn't show anything. So 2 problems, colord dumping and abrt-gui not reporting. It was probably running under different user then who is running the abrt-gui so gui can't access it and doesn't show it. You can try to run the gui as root to see all the crashes. J. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: colord core dump and abrt not reporting
On 05/20/2011 04:48 PM, Gianluca Cecchi wrote: On Fri May 20 10:28:21 UTC 2011 Jiri Moskovcak wrote: It was probably running under different user then who is running the abrt-gui so gui can't access it and doesn't show it. You can try to run the gui as root to see all the crashes. I had this problem too and indeed running the gui from root let the crash appear. It resulted that Neal had already opened same bug and so a comment was added for me in: https://bugzilla.redhat.com/show_bug.cgi?id=705005 - Great! Good to see that the dupe detection works ;) J. Gianluca -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: abrt not reporting
On 05/16/2011 01:07 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 05/15/2011 09:05 PM, Neal Becker wrote: Here's another one. May 15 14:32:40 nbecker1 kernel: [13788.265548] at-spi-registry[3807]: segfault at 18 ip 003ad50259a1 sp 7fff8ed82dc0 error 4 in libgconf-2.so.4.1.5[3ad500+3b000] May 15 14:32:40 nbecker1 abrt[3808]: saved core dump of pid 3807 (/usr/libexec/at-spi-registryd) to /var/spool/abrt/ccpp-2011-05-15-14:32:40-3807.new/coredump (1359872 bytes) Again, abrt doesn't show anything to report. Looks like abrt isn't working. - it's probably because it runs as a different user than who is running the abrt-gui (abrt-cli). Try to run abrt as root. Jirka. OK, I ran abrt-gui as root. I got it to work, but it's really annoying - it keeps complaining can't connect to gnome keyring. (Manually set username+password in /etc/abrt/events/report_Bugzilla.conf.) - I know about this problem: https://fedorahosted.org/abrt/ticket/210 and I promise we will fix it, but the proper fix will require a lot of coding, so please be patient ;) Have a nice day Jirka -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: abrt cache size 'out of control' in F15
On 05/15/2011 12:18 PM, Frederic Muller wrote: Hi! I just did a rm -Rf * on /var/cache/abrt-di/ as it was 3.2GiB and growing. After checking the 927 bugs related to abrt I could only find this one https://bugzilla.redhat.com/show_bug.cgi?id=529573 which matches my issue but relates to F12 and where maintainer says: Abrt watches for the space filled by backtraces, it's quota can be changed in config file /etc/abrt/abrt.conf. The default value is 1G. My abrt.conf does have MaxCrashReportsSize = 1000 but it doesn't seem to work neither. - is not a quota for debug infos but for saved crashes - the quota for debuginfos in ABRT2 (F15) is 4GB and is configurable in /etc/abrt/events.d/ccpp_event.conf line: abrt-action-install-debuginfo --size_mb=4096 - we will provide better documentation soon J. Shall I reopen that same bug, or create a new one? Thanks. Fred -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: abrt cache max size in F15
On 05/15/2011 01:06 PM, Frederic Muller wrote: On 05/15/2011 07:01 PM, Frederic Muller wrote: On 05/15/2011 06:47 PM, Jiri Moskovcak wrote: On 05/15/2011 12:18 PM, Frederic Muller wrote: Hi! I just did a rm -Rf * on /var/cache/abrt-di/ as it was 3.2GiB and growing. After checking the 927 bugs related to abrt I could only find this one https://bugzilla.redhat.com/show_bug.cgi?id=529573 which matches my issue but relates to F12 and where maintainer says: Abrt watches for the space filled by backtraces, it's quota can be changed in config file /etc/abrt/abrt.conf. The default value is 1G. My abrt.conf does have MaxCrashReportsSize = 1000 but it doesn't seem to work neither. - is not a quota for debug infos but for saved crashes - the quota for debuginfos in ABRT2 (F15) is 4GB and is configurable in /etc/abrt/events.d/ccpp_event.conf line: abrt-action-install-debuginfo --size_mb=4096 - we will provide better documentation soon J. Well then I'm still within the limit and can now adjust my default max size. Thank you very much. Fred Actually there are 2 lines with the same parameters, one in this section: EVENT=analyze_LocalGDB analyzer=CCpp backtrace= and that section: EVENT=reanalyze_LocalGDB analyzer=CCpp So do the 2 sizes add up in the same sub-directory making a total of 8GiB or else how does it work? I have only 10GiB allocated to / (and /home is on a separate partition). - no, they don't sum, but to make it work right, you need to change both lines - this is not necessary with the latest upstream version, so I will create an update as soon as it's stable. J. Thank you. Fred -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: ABRT problems
On 04/01/2011 03:33 PM, Steven Stern wrote: Nautilus crashed and abrt popped up. First, I selected the option to do send the report to the remote analyzer. That hung with Certificate is signed by an untrusted issuer: 'E=mto...@redhat.com,CN=retrace01.fedoraproject.org,OU=BaseOS,O=Red Hat,L=Brno,C=CZ'. PENDING - it doesn't hung, it just takes really long, it depends on the size of application and it's dependencies.. Then I tried to process it locally, with no good results. (Selinux is in permissive mode.) - and this is probably rhbz#692064 Analyzing coredump '/home/sdstern/.abrt/spool/ccpp-2011-04-01-08:10:08-5377/coredump' Coredump references 133 debuginfo files, 116 of them are not installed Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15arch=i386 error was No repomd file Looking for needed packages in repositories Packages to download: 75 Downloading 414.41Mb, installed size: 1937.72Mb Downloading (1 of 75) file-roller-debuginfo-2.91.93-1.fc15.i686.rpm: 100% Extracting cpio from /tmp/abrt-tmp-debuginfo-2011-04-01-08:11:54.5521/file-roller-debuginfo-2.91.93-1.fc15.i686.rpm Caching files from unpacked.cpio made from file-roller-debuginfo-2.91.93-1.fc15.i686.rpm cpio: ./usr/lib/debug: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxrwxr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/36: Cannot mkdir: Permission denied cpio: cannot make directory `./usr/lib/debug/.build-id/36': Permission denied cpio: ../../../nautilus/extensions-3.0/libnautilus-fileroller.so: Cannot symlink to `./usr/lib/debug/.build-id/36/d6dff843c385f3b67f2bfb01e0e9a61b6483a9': No such file or directory cpio: cannot make directory `./usr/lib/debug/.build-id/36': Permission denied cpio: ../../usr/lib/nautilus/extensions-3.0/libnautilus-fileroller.so.debug: Cannot symlink to `./usr/lib/debug/.build-id/36/d6dff843c385f3b67f2bfb01e0e9a61b6483a9.debug': No such file or directory cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxrwxr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/5b: Cannot mkdir: Permission denied cpio: cannot make directory `./usr/lib/debug/.build-id/5b': Permission denied cpio: ../../../../libexec/file-roller-server: Cannot symlink to `./usr/lib/debug/.build-id/5b/e18d6fe01c1ed18ac6fe18a5086955c2fd7368': No such file or directory cpio: cannot make directory `./usr/lib/debug/.build-id/5b': Permission denied cpio: ../../usr/libexec/file-roller-server.debug: Cannot symlink to `./usr/lib/debug/.build-id/5b/e18d6fe01c1ed18ac6fe18a5086955c2fd7368.debug': No such file or directory cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxrwxr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/82: Cannot mkdir: Permission denied cpio: cannot make directory `./usr/lib/debug/.build-id/82': Permission denied cpio: ../../../../libexec/file-roller/rpm2cpio: Cannot symlink to `./usr/lib/debug/.build-id/82/62f62312db833c5e204b200ec7662feb5197c5': No such file or directory cpio: cannot make directory `./usr/lib/debug/.build-id/82': Permission denied cpio: ../../usr/libexec/file-roller/rpm2cpio.debug: Cannot symlink to `./usr/lib/debug/.build-id/82/62f62312db833c5e204b200ec7662feb5197c5.debug': No such file or directory cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxrwxr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/a1: Cannot mkdir: Permission denied cpio: cannot make directory `./usr/lib/debug/.build-id/a1': Permission denied cpio: ../../../../bin/file-roller: Cannot symlink to `./usr/lib/debug/.build-id/a1/f5186909a466afbb5a1e9f0c018c8a949fe6e4': No such file or directory cpio: cannot make directory `./usr/lib/debug/.build-id/a1': Permission denied cpio: ../../usr/bin/file-roller.debug: Cannot symlink to `./usr/lib/debug/.build-id/a1/f5186909a466afbb5a1e9f0c018c8a949fe6e4.debug': No such file or directory cpio: ./usr/lib/debug/usr: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr/bin: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr/bin: Cannot change mode to rwxrwxr-x: Operation not permitted cpio: ./usr/lib/debug/usr/bin/file-roller.debug: Cannot open: Permission denied cpio: ./usr/lib/debug/usr/lib: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/usr/lib: Cannot change mode to rwxrwxr-x: Operation not permitted cpio: ./usr/lib/debug/usr/lib/nautilus: Cannot mkdir: Permission denied cpio: cannot make directory `./usr/lib/debug/usr/lib/nautilus': Permission denied cpio: ./usr/lib/debug/usr/lib/nautilus/extensions-3.0: Cannot mkdir: No such file or directory cpio: cannot make directory `./usr/lib/debug/usr/lib/nautilus': Permission denied cpio:
Re: Running abrt-cli in live isos for graphics test days?
I just tested this again and it still doesn't appear to be working. Task ID was 395668768 and password ZE8NvUgmhlUKXI1KQWY4gxePcoq4b341 if you want to check it out yourself. The log ends with: file:///var/cache/abrt-retrace/fedora-15-x86_64-updates/repodata/repomd.xml: [Errno 14] Could not open/read file:///var/cache/abrt-retrace/fedora-15-x86_64-updates/repodata/repomd.xml Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: updates. Please verify its path and try again Thanks! Should be fixed now. Jirka -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Running abrt-cli in live isos for graphics test days?
On 02/24/2011 10:08 AM, mike cloaked wrote: On Thu, Feb 24, 2011 at 8:46 AM, Jiri Moskovcakjmosk...@redhat.com wrote: The new ABRT version will have option to use the retrace server instead of the local retracing. The new version should be out in a few days (at least in git and my personal repo). Before that anyone interested can find the retrace client cmdline tool (better than the mentioned script) in retrace branch in abrt git. J. Do you have a url to get the retrace cmdline tool please? I am very keen to use this to get at a backtrace to help diagnose a serious gnome3 problem for F15 alpha - and secondly is the new cmdline tool working with f15 currently? Thanks The retrace server for F15 should be working now. To use it please go to http://fedoraproject.org/wiki/Features/RetraceServer and you'll find everything needed in section How To Test. Don't hesitate to ping us on freenode #abrt if something doesn't work as expected. Jirka -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Running abrt-cli in live isos for graphics test days?
On 02/23/2011 08:38 PM, Samuel Greenfeld wrote: Just curious, but has anyone considered something like Microsoft's symbol server system, which can download symbols for specific executable files from one or more central repositories? They have public servers which can be used to download symbols for released products, and private ones can be setup as well. (I would not know the legal logistics of setting up a similar system.) There was something like it: http://fedoraproject.org/wiki/Features/DebuginfoFS but it's dead now, if they are some people interested to bring this idea back, it would be awesome. J. --- SJG On 02/23/11 14:06, John Watzke wrote: What we really want is to use the retrace server: http://fedoraproject.org/wiki/Features/RetraceServer I should test using that and document it. That sounds interesting. As long as it has some security in place it would sound great. The nice thing about backtraces is that the user can take a look at what is being sent and thus take out sensitive data. If the cores were transmitted with SSL and locked down so that no one (other than the admins of course which we hope we trust) would ever had access to the original core files, then it might work. It seems like there is this kind of security discussed... of course, you still have to trust the super users. -- John Watzke -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Running abrt-cli in live isos for graphics test days?
On 02/23/2011 10:27 PM, Adam Williamson wrote: On Wed, 2011-02-23 at 12:46 -0800, Adam Williamson wrote: On Wed, 2011-02-23 at 19:50 +, mike cloaked wrote: On Wed, Feb 23, 2011 at 5:51 PM, Adam Williamsonawill...@redhat.com wrote: What we really want is to use the retrace server: http://fedoraproject.org/wiki/Features/RetraceServer I should test using that and document it. Maybe I am a bit dim but I can't find any documentation on this apart from the wiki and trac entries - but nothing in the abrt koji info seems to say if it is included now or how to use it. Is there a pointer/url to using it that I can access? There's a script linked from the wiki page which you can just download and run and should work, I think. All you really need to do on the client end is send the traceback to the server, all the complex stuff happens on the server, so the requirements aren't heavy. I just tested it, it seems to not work with F15 reports atm. I've let the abrt team know, I hope they'll fix it. The retrace server is being deployed for F15 right now. This process can take a few hours, so we will send an update (with links to required tools) as soon as it finishes. Btw even when the server is uprunning it will be probably slow and can't take many simultaneous requests at once - it's still running on a testing HW (which should change soon). Sorry for any inconvenience, Jirka -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
