Crash-catcher

crash-catcher@lists.fedorahosted.org

2024 discussions

dump dir upload page not intuitive
by Jan Hutař 13 May '19

13 May '19

Hello, because automatic reporting failed ('report_uReport' exited with 1), I have attempted to upload crash dir manually and failed as well. First I have not read whole text and just did: cd /var/spool/abrt sudo tar cf 'aaa.tar.gz' Python3-2019-05-11-21\:14\:04-25765 and uploaded that. Page said "Wrong archive file name". Then I realized that maybe I need to create tar without dir and use all the tar options mentioned there: cd /var/spool/abrt/Python3-2019-05-11-21:14:04-25765 sudo tar -pczf /tmp/aaa.tar.gz * Same result. Then I noticed page says "into 'tar.gz' file" which is to me unusual name, but I tried: cd /var/spool/abrt/Python3-2019-05-11-21:14:04-25765 sudo tar -pczf /tmp/tar.gz * Same result. Now I realized that click to "upload" link in "Problem Reporting" took me to URL: https://retrace.fedoraproject.org/faf/dumpdirs/new/Python3-2019-05-11-21:14… So maybe page expects that? cd /var/spool/abrt/Python3-2019-05-11-21:14:04-25765 sudo tar -pczf /tmp/Python3-2019-05-11-21\:14\:04-25765.tar.gz * That finally worked and I got "Dump dir archive already exists." so looks like something before worked. Could the page be made more fool-proof? Maybe: - mentioning in which directory to run the tar command - menitioning expected name of the archive - or ability to consume fine no matter what name it have - maybe also showing note that file is already uploaded Thank you in advance, Jan -- Jan Hutar Satellite QA jhutar(a)redhat.com Red Hat, Inc.

2 1

Abrt sometimes deleting all crashes
by Christian Stadelmann 21 Dec '16

21 Dec '16

Lately, I'm seeing a weird behavior of abrt happening over and over again: Although I have just a few (say, 4) smaller crashes (not WebKit or Firefox), which take up little space on my disk, when a new crash happens, some or even all crashes are deleted. abrtd then reports to syslog: abrtd[896]: Size of '/var/spool/abrt' >= 25000 MB (MaxCrashReportsSize), deleting old directory 'ccpp-2016-12-… This way, I never get more than 6 crashes listed by gnome-abrt or abrt-cli. Sometimes, abrt even deletes all my crash directories, including small python backtraces with just a few megabytes. I don't understand why this happens. Can you please tell me? Is this a bug? After the last crash happened (firefox, https://bugzilla.redhat.com/show_bug.cgi?id=1404439), all crashes were deleted. This is the filesystem state of abrt directories after that crash: /var/cache/abrt-di is 800 MB although there is no crash present any more. /var/spool/abrt-upload is empty. /var/spool/abrt and /var/lib/abrt and /var/run/abrt just contain some very small files. This is all abrt-related stuff in my syslog from last boot, where abrt deleted all my crashes (19:25:58): https://gist.github.com/anonymous/348e3101aa18c5f0d862f8396a3f97f0 I already tried to purge/delete all the files listed above and reinstall all of abrt, but there is no change, the issue doesn't go away. Two probably unrelated questions: 1. I know that the "firefox" package is signed with a proper key, but I installed it from command line after manually downloading it from koji. Abrt throws away this crash and logs: Dez 13 21:13:14 hostname abrt-hook-ccpp[3199]: Process 30672 (firefox) of user 1000 killed by SIGSEGV - dumping core Dez 13 21:13:15 hostname abrt-hook-ccpp[3199]: Failed to create core_backtrace: PTRACE_SEIZE (tid 30766) failed: Operation not permitted Dez 13 21:13:15 hostname abrt-server[3202]: Package 'firefox' isn't signed with proper key Dez 13 21:13:15 hostname abrt-server[3202]: 'post-create' on '/var/spool/abrt/ccpp-2016-12-13-21:13:14-30672' exited with 1 Dez 13 21:13:15 hostname abrt-server[3202]: Deleting problem directory '/var/spool/abrt/ccpp-2016-12-13-21:13:14-30672' What am I doing wrong? Because of abrt deleting my crashes, I get these a lot: "ignoring (repeated crash)". How can I reset abrt's behavior about crashes it has seen before?

3 6

Re: Fwd: Abrt sometimes deleting all crashes
by Miroslav Suchý 20 Dec '16

20 Dec '16

> Lately, I'm seeing a weird behavior of abrt happening over and over again: > > Although I have just a few (say, 4) smaller crashes (not WebKit or > Firefox), which take up little space on my disk, when a new crash > happens, some or even all crashes are deleted. abrtd then reports to > syslog: > abrtd[896]: Size of '/var/spool/abrt' >= 25000 MB > (MaxCrashReportsSize), deleting old directory 'ccpp-2016-12-… > > This way, I never get more than 6 crashes listed by gnome-abrt or > abrt-cli. Sometimes, abrt even deletes all my crash directories, > including small python backtraces with just a few megabytes. > > I don't understand why this happens. Can you please tell me? Is this a bug? See /etc/abrt/abrt.conf: # Max size for crash storage [MiB] or 0 for unlimited # MaxCrashReportsSize = 1000 -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys

2 1

RFC: ABRT integration
by Jakub Filak 15 Nov '16

15 Nov '16

Avocado developers, I came across an Avocado trello card requesting integration with systemd-coredumpctl. As a developer working on Automatic Bug Reporting Tool (ABRT) I got interested in it. I contacted Lukas Doktor with a question of what purpose the integration should be and with an offer to engage ABRT too. After short chat he asked me to send an RFC to this mailing list. So here you are Lukas. Let me first briefly introduce ABRT. Despite its name ABRT is more about detecting software (and hardware) problems and the reporting is just a one step in the whole processes of handling a problem. Currently ABRT is capable of detecting core files, uncaught Python exceptions, uncaught Ruby exceptions, uncaught Java exceptions, Kernel oopses (including those stored in pstore), Kernel vmcores and Machine Check Exceptions. ABRT provides several ways accessing detect problems which includes command line tools (abrt), GUI tools (gnome-abrt), Python API, C API and D-Bus interface. If interested, you can find more about ABRT at: http://abrt.readthedocs.io/ I propose to enhance Avocado to become aware of ABRT and include detected problems in test results. Here is my initial proof-of-concept commit: https://github.com/jfilak/avocado/commit/e3258706bdfffb8ddddb2f1bc51328af29… Some technical details: - the implementation will capture only problems of a current user - a proper configuration of PolicyKit can allow any user to read all system problems - there can be several simultaneous connections to ABRT D-Bus connection Please have a look at my patch and let me know if ABRT integration is something you are interested in. Should you have any question, please contact me or any ABRT developer on crash-catcher(a)lists.fedorahosted.org or on #abrt. Kind regards, Jakub

3 3

AppData additions required for the software center
by Richard Hughes (semi-automated) 10 Aug '16

10 Aug '16

Hi again! First, apologies for the direct email. I'm emailing you directly as you've been listed as the update contact in one or more AppData files. We've been busy building an awesome software center, and we've been adding more and more metadata fields that upstream authors can set. The software center is now being used in Fedora, Opensuse, Ubuntu, Debian and Arch, with many millions of happy users. Some of the newest features include a way to make it easy for translators to contribute new translations of your applications by specifying a URL in the gnome-abrt.appdata.xml AppData file that tells them where to start looking. This can be specified by adding: <url type="translate">http://the-web-site-with-translation-instructions/</url> Another useful tag to add is to tell end-users where to donate, for instance: <url type="donation">http://www.gnome.org/friends/</url> If it's been some time since you updated the AppData file (and hey, you've got an app to write!) you can get add the latest metadata fields by doing `appstream-util upgrade gnome-abrt.appdata.xml` and then replacing any FIXMEs in the file with actual data. We'll be putting more functionality into the software center in the future that uses this extra data, but we need more upstream software to opt-in before we can enable features, for instance, providing a button for users to donate to specific apps. You can also use `appstream-util validate-relax` on your AppData file to check the various fields meet our style guidelines. If you disagree with any of the validation warnings, please let me know! Of course, you don't have to do a release with these enhancements straight away, and if you have a stable branch it would be a good thing to backport this as well if it does not add translated strings or you have no string freeze policy. When you've changed the file(s) and committed, please email me back and I'll mark your application as completed. If you don't want to hear from me ever again just edit the <update_contact> in the AppData file and change it to somebody else. I'm not planning on emailing more than once every 6 months, so don't worry about me spamming you with even more work to do. Thanks, Richard

1 0

Creating DSO list for all types of crashes
by Matej Habrnal 30 May '16

30 May '16

Reason ------ CuCos developers need to get involved packages in crashes but not only rpm but rubygem and so on as well. Current state ------------- ABRT creates DSO list (dynamically loaded libraries or modules) only for CCpp xorg, and Python2 type of problems. In CCpp and xorg type it's created by following steps: in post-create envet is run abrt-action-list-dsos tool with parameter maps (/proc/$PID/maps), respectively, with backtrace and the tool generate dso list by calling '$ rpm -rf $PATH' on every given path from maps, respectively, backtrace. The resulting dso_list file then looks like following (path, package, vendor, install time): "" /usr/lib64/libc-2.23.so glibc-2.23.1-7.fc24.x86_64 (Fedora Project) 1463385519 /usr/lib64/libwillcrash.so.0.0.0 will-crash-0.10-2.fc24.x86_64 (Fedora Project) 1461672440 /usr/lib64/ld-2.23.so glibc-2.23.1-7.fc24.x86_64 (Fedora Project) 1463385519 /usr/bin/will_segfault will-crash-0.10-2.fc24.x86_64 (Fedora Project) 1461672440 "" In Python type the dso_file is created from backtrace right in abrt_exception_handler.py, it means in time the exception was caught. Every path from backtrace is run with 'rpm -rf $PATH' and look like following (package): "" will-crash-0.10-2.fc24.x86_64 "" DSO list is not generated for other types. Goal ---- Unify generating of DSO files and add support for all types of crashes (Python3, java, ruby etc.). Allow easily add a new crash type, ideally propose some API in order to use it in plugins like ruby. Move current dso_list generating from post-create event and python hook to make post-create faster. Proposed solution ----------------- Split curren dso_list generating into three parts and extend it by adding new crash types. First step ~~~~~~~~~~ First part should generate simple dso_list which contains only path to linked libraries or modules. This part should be placed in satyr because satyr can handle backtraces. Will be used JSON format, because the file will be loaded and parsed in each step and it's easy to do that with JSON file. Satyr also creates JSON structure of dso_list while it creates uReport. So it should make uReport creating faster as well. All path will be stored as file_name and each file_name has its own type element. The type element says if there is detail information related to the path, it means if information about package which ships the path is known. In the first step all type elements are set to undefined value. Example: Basic dso_file generated by satyr: { "packages": [ { "file_name": "/usr/lib64/libc-2.23.so" , "type": "undefined" } , { "file_name": "/some/java/file" , "type": "undefined" } , { "file_name": "/usr/lib64/ld-2.23.so" , "type": "undefined" } ] } Second step ~~~~~~~~~~~ The second part will be placed in ABRT and its main purpose will be getting more information (package which ships the path, its vendor and time of installation etc.) about paths from dso_list which is made by part one. For main types of packages as rpm, deb etc. there will be some mechanisms to get the information (e.g. rpm -qf $PATH for paths shipped by rpm package). ABRT will go through all file_names from dso_list and will try all mechanisms to all given file_names and compete them. ABRT updates the dso_file so the file now contains some package with full information and some packages are unchanged. In the case package contains full information, ABRT stores type of mechanism which gets the information into type element, it ensures third step cannot try to get them. Package containing only file_name and type with value undefined will handle the part three. ABRT could handle following types in part two: rpm ruby pip Example: dso_file content after second step: "packages": [ { "file_name": "/usr/lib64/libc-2.23.so" , "type": "rpm" , "name": "glibc" , "epoch": 0 , "version": "2.23.1" , "release": "7.fc24" , "architecture": "x86_64" , "install_time": 1463385519 } , { "file_name": "/some/java/file" , "type": "undefined" } , { "file_name": "/usr/lib64/ld-2.23.so" , "type": "rpm" , "name": "glibc" , "epoch": 0 , "version": "2.23.1" , "release": "7.fc24" , "architecture": "x86_64" , "install_time": 1463385519 } } ] Third step ~~~~~~~~~~ Step three should complete the dso_list. Mechanism for special types (e.g. Java), will be shipped with plugins which process those crashes (e.g. abrt-java-conector). The plugins should handle completing the dso_list on its own. Example: dso_file content after third step: "packages": [ { "file_name": "/usr/lib64/libc-2.23.so" , "type": "rpm" , "name": "glibc" , "epoch": 0 , "version": "2.23.1" , "release": "7.fc24" , "architecture": "x86_64" , "install_time": 1463385519 } , { "file_name": "/some/java/file" , "type": "java" , "name": "java_name" , "epoch": 0 , "version": "2.23.1" , "release": "7.fc24" , "architecture": "x86_64" , "install_time": 1463385519 } , { "file_name": "/usr/lib64/ld-2.23.so" , "type": "rpm" , "name": "glibc" , "epoch": 0 , "version": "2.23.1" , "release": "7.fc24" , "architecture": "x86_64" , "install_time": 1463385519 } } ] This is just the first idea. Feel free to propose some improvements or ideas. Regards Matej ABRT team

1 0

Keywords required for the software center
by Richard Hughes (semi-automated) 07 Jan '16

07 Jan '16

Hi! First, apologies for the direct email. I'm emailing you directly as you've been listed as the update contact in one or more AppData files. In the software center we allow the user to search using case-insensitive keywords, for instance searching for 'excel' could match Libreoffice Calc or many other free software spreadsheet applications. At the moment we use the translated keywords set in the desktop file, any extra <keyword> entries in the AppData file, and then fall back to generating tokens from the name, summary and description using a heuristic. This heuristic works most of the time, but a human can often do much better when we know what the most important words are. I've noticed your application does not have any manually set keywords and thought I should bring this to your attention. So, what do I want you to do? Basically, I would like you to add some keywords in the gnome-abrt.desktop file or the gnome-abrt.appdata.xml AppData file. If you want the keywords to be used by GNOME Shell as well (which you probably do), the best place to put any search terms is in the keywords section [1] of the desktop file. This can also be marked as translatable so non-English users can search in their own language. This would looks something like Keywords=3D;printer; (remember the trailing semicolon!) The alternative is to put the keywords in the AppData file so that they are only used by the software center and not the desktop shell. You can of course combine putting keywords in both places. The AppData keywords can also be translated, and would look like this: <keywords> <keyword>3D</keyword> <keyword>printer</keyword> </keywords> Of course, you don't have to do a release with this fix straight away, and if you have a stable branch it would be a good thing to backport this as well if it does not add translated strings or you have no string freeze policy. Nothing bad will happen if you ignore this email, but please be aware that matches from keywords are ordered higher in the search results than other partial matches from the name or summary. You also don't have to add keywords that are the same as the application name or package name, as these are automatically added as case insensitive search tokens. When you've changed the file(s) and committed, please email me back and I'll mark your application as completed. If you don't want to hear from me ever again just edit the <update_contact> in the AppData file and change it to somebody else. I'm not planning on emailing more than once every 6 months, so don't worry about me spamming you with even more work to do. If you don't add the keywords then your application will still be visible in the various software centers, but it may be harder to find. Thanks, Richard [1] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-late…

1 0

Additions required to the AppData file
by Richard Hughes (semi-automated) 04 Dec '15

04 Dec '15

Hi! First, apologies for the direct email. I'm emailing you directly as you've been listed as the update contact in one or more AppData files. In future versions of the appstream-builder (the program used by distributions to merge all the AppData files in packages into AppStream metadata) we're going to be running a lot less crazy plugins. At the moment we're doing things like parsing .gir files, running nm on binaries and looking up things from arrays of hardcoded data just so we can try and work out what kudos the application deserves. This doesn't scale, and means the machine generating the metadata needs to have all kinds of extra build tools installed. So, what do I want you to do? Basically, I would like you to: Add the following data into gnome-abrt.appdata.xml <kudos> <kudo>HiDpiIcon</kudo> <kudo>HighContrast</kudo> <kudo>ModernToolkit</kudo> </kudos> Of course, you don't have to do a release with this fix straight away, and if you have a stable branch it would be a good thing to backport this as well. Nothing bad will happen if we run the automated tools with the kudos already set in the AppData file. If you think any of the other kudos might apply[1], please email me back and we can discuss any new additions. When you've changed the file and committed, please email me back and I'll mark your application as completed. If you don't want to hear from me ever again just edit the <update_contact> in the AppData file and change it to somebody else. I'm not planning on emailing any of you again this year, so don't worry about me spamming you with even more work to do. If you don't add the manual <kudos> then your application will still be visible in the various software centers, but it may loose some of the stars it got auto-assigned. Thanks, Richard [1] https://git.gnome.org/browse/gnome-software/plain/doc/kudos.md

2 1

ABRT allow blacklisting dumps and add user whitelist
by Matej Habrnal 13 Nov '15

13 Nov '15

ABRT allow blacklisting dumps and add user whitelist ==================================================== Related bugzillas: #1208713, #1256705 Allow blacklisting applications/exe-paths/packages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Current state ------------- There is a possibility to blacklist packages or paths in '/etc/abrt/abrt-action-save-package-data.conf' options 'BlackList' for packages and option 'BlackListedPaths' for paths. The blacklisting is not done in time when the crash occurs but while the abrt-action-save-package-data tool is executing so in 'post-create' event after the coredumps are written to disk. Suggestions ----------- The new blacklisting feature should prevent of dumping blacklisted executables/paths already in dumping time, therefore it must be moved from abrt-action-save-package-data to abrt-hook-ccpp. Have to notice ABRT is marked as a tool for developers and developers want coredumps of their applications. If the 'post-create' event fails because of 'abrt-action-save-package-data' (e.g. the package is blacklisted or the executable file is not signed or don't belong to any package etc.), the created dump dir, also with coredump, is removed and developers cannot analyse it. Creating unwanted directories and deleting them in the next step don't make much sense. Another example: If the option 'OpenGPGCheck' is set to 'no' and 'ProcessUnpackaged' set to 'yes', it means ABRT catches all crashes on the system and makes them reportable to the bugzilla or to another bug tracking system even if it's not possible because usually there is no such component in bug tracking system. jfilak suggested to not delete crashes which pass through main blacklisting in 'abrt-hook-ccpp' and at the same time don't pass through 'abrt-action-save-package-data' but mark them as 'not-reportable'. This allows the developers analyse them later or configure ABRT, for example, to sent all crashes, even the not reportable one, via email or to FTP server. Conclusion ---------- 1) mark crashes which don't pass through abrt-action-save-package-data as not-reportable like was mentioned above 2) introduce a new dump dir element, something like 'unsupported', which disallow reporting crashes only to bug tracking systems Other things ------------ We have to decided which of abrt-action-save-package-data.conf's options (OpenGPGCheck, BlackList, ProcessUnpackaged and BlackListedPaths) will stay in the conf file or which one will be renamed. My suggestions: BlackList -> NotSupportPackages BlackListedPaths -> NotSupportPaths OpenGPGCheck - without changes ProcessUnpackaged - without changes, but if its value is 'true', all the unpackaged apps will be marked as not-reportable (unsupported). Add user whitelist ~~~~~~~~~~~~~~~~~~ Current state ------------ Is not possible to catch crashes only from given users. Suggestions ----------- This option should be added to abrt-hook-ccpp (so to the CCpp.conf file) because we have to stop processing the crash in the very beginning and do not create and then remove created dirs like it is done during processing of events. conclusion ---------- Add option to the CCpp.conf file like 'ProcessCrashFromUsers'. If there are no user names or the option is not presented, ABRT process crashes from all users. If there are specified user names, ABRT process crashes from given users. Matej

1 0

Issue
by Michael Buckley 01 Oct '15

01 Oct '15

I got an email a while ago on checking one of my fedora hosted lists I was on, and it looks like a password problem. I was asked to change the password because it did not fit the rules for a password (need a special character I got a hit on). I tried changing the password, but It hung up on saying the old password was an invalid format. Look like a catch-22. Mike

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Crash-catcher