Here's some of my pet irritations with abrt. Feel free to add your own, but please keep the gratuitous "me too"ing to a minimum.
1) The generated reports contain far too little information for library owners. Consider this report:
https://bugzilla.redhat.com/show_bug.cgi?id=658013
I get the EVRs for the kernel, and for the executable that happened to be running, but not for any of the libraries in between, even though the report very carefully tells me exactly which DSOs are loaded and where they are in memory.
2) I really dislike that "local trace generation" and "retrace server" are discussed as though they're the only options. If nothing else, for many non-trivial apps where abrt is potentially of the most use the core you're uploading can easily be hundreds of megabytes; that's not really better than downloading hundreds of megabytes. A network debuginfo service [1] would approach this problem in a completely different way, by letting the client download exactly as much debuginfo as it needs.
3) Reporting to bugzilla is a mistake.
4) Reporting to bugzilla without being able to scrape the bz username and password out of the firefox credential store is just cruel.
[1] - http://git.fedorahosted.org/git/?p=littlebottom.git;a=summary
- ajax
On Thu, 2010-12-09 at 10:51 -0500, Adam Jackson wrote:
Here's some of my pet irritations with abrt. Feel free to add your own, but please keep the gratuitous "me too"ing to a minimum.
- The generated reports contain far too little information for library
owners. Consider this report:
https://bugzilla.redhat.com/show_bug.cgi?id=658013
I get the EVRs for the kernel, and for the executable that happened to be running, but not for any of the libraries in between, even though the report very carefully tells me exactly which DSOs are loaded and where they are in memory.
Gratuitous me too!
But more seriously, I filed this a while back as: https://bugzilla.redhat.com/show_bug.cgi?id=555205 "RFE: include "rpm -qf" output for all memory-mapped DSOs"
This would be a great boon to things like python where you can have an arbitrary amount of DSOs mapped into your process, from pretty much the whole of the distribution (which is both a good and a bad thing; would love to sandbox python modules, but that's an unsolved problem, AIUI).
- I really dislike that "local trace generation" and "retrace server"
are discussed as though they're the only options. If nothing else, for many non-trivial apps where abrt is potentially of the most use the core you're uploading can easily be hundreds of megabytes; that's not really better than downloading hundreds of megabytes. A network debuginfo service [1] would approach this problem in a completely different way, by letting the client download exactly as much debuginfo as it needs.
Another gratuitous me too, see: https://fedoraproject.org/wiki/Talk:Features/RetraceServer
I'm wondering why the network debuginfo service couldn't be simply wired up to Koji's rpm via readonly NFS and scrape debugingo rpms on demand.
- Reporting to bugzilla is a mistake.
FWIW, I'll mention again my ABRT triage scripts; they help me keep sane whre dealing with incoming crash reports: http://fedorapeople.org/gitweb?p=dmalcolm/public_git/triage.git;a=tree
(The heuristics there are targetting python crash reports, since that what I get)
- Reporting to bugzilla without being able to scrape the bz username
and password out of the firefox credential store is just cruel.
Seems like this should in bugzilla.
Hope this is helpful Dave
On Thu, 09 Dec 2010 17:10:49 +0100, David Malcolm wrote:
Another gratuitous me too, see: https://fedoraproject.org/wiki/Talk:Features/RetraceServer
Detailed description: [...] User sends the coredump [...]
Do you intend to make it default for Fedora?
So far I thought it is not acceptable and in many cases my request in BZ for a core dump was refused by a user due to security concerns.
OTOH the system binaries are already provided by the Fedora project and if the retrace server infrastructure has the same security as Koji servers the security level stays the same.
Thanks, Jan
On 12/14/2010 03:51 AM, Jan Kratochvil wrote:
On Thu, 09 Dec 2010 17:10:49 +0100, David Malcolm wrote:
Another gratuitous me too, see: https://fedoraproject.org/wiki/Talk:Features/RetraceServer
Detailed description: [...] User sends the coredump [...]
Do you intend to make it default for Fedora?
- not decided yet, but I'm thinking about something user friendly like dialog saying:
How do you want to generate the backtrace? 1. Locally (will download XY MB of debuginfo and you need gdb and etc..) 2. I want to use the RS (WARNING!!: will upload the core file which may contain a sensitive data, but provides a better backtrace) 3. I need to ask my older brother, so cancel the reporting ...
So far I thought it is not acceptable and in many cases my request in BZ for a core dump was refused by a user due to security concerns.
- some people won't send it some will.. When I can't reproduce the bug and user doesn't want to send me the core, then sorry -> CLOSED INSUFF_INFO what else can you do?
OTOH the system binaries are already provided by the Fedora project and if the retrace server infrastructure has the same security as Koji servers the security level stays the same.
- exactly if we want to get user's private data there is many easier ways then to build a server and write a special app for it...
But the core definitely won't be uploaded without making sure that user understands what he is about to upload, as we don't want to get under the same critic as one of the well known operating system developer :)
Jirka
Gathering the RFEs at: https://fedorahosted.org/abrt/wiki/Wishlist
On 12/09/2010 04:51 PM, Adam Jackson wrote:
Here's some of my pet irritations with abrt. Feel free to add your own, but please keep the gratuitous "me too"ing to a minimum.
- The generated reports contain far too little information for library
owners. Consider this report:
https://bugzilla.redhat.com/show_bug.cgi?id=658013
I get the EVRs for the kernel, and for the executable that happened to be running, but not for any of the libraries in between, even though the report very carefully tells me exactly which DSOs are loaded and where they are in memory.
- added as "add NVRs for loaded libraries"
- I really dislike that "local trace generation" and "retrace server"
are discussed as though they're the only options. If nothing else, for many non-trivial apps where abrt is potentially of the most use the core you're uploading can easily be hundreds of megabytes; that's not really better than downloading hundreds of megabytes. A network debuginfo service [1] would approach this problem in a completely different way, by letting the client download exactly as much debuginfo as it needs.
I mentioned the debuginfofs many times in ABRT flames, there was however a problem with our debug tools making it unusable, because one had to read the whole debuginfo file from the server and few other problems so that's why the retrace server idea came up. but this should fixed in the current tools so theoretically nothing prevents us from reviving it.. once this is done ABRT can easily use it...
- Reporting to bugzilla is a mistake.
- added as: "don't report directly to bz"
- Reporting to bugzilla without being able to scrape the bz username
and password out of the firefox credential store is just cruel.
- added as: "share bz credential with other apps" - not sure if we can share the credentials with firefox, but we can share it with apps that store it in the gnome-keyring (which ff doesn't)
[1] - http://git.fedorahosted.org/git/?p=littlebottom.git;a=summary
- ajax
On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:
- Reporting to bugzilla without being able to scrape the bz username
and password out of the firefox credential store is just cruel.
- added as: "share bz credential with other apps"
- not sure if we can share the credentials with firefox, but we can
share it with apps that store it in the gnome-keyring (which ff doesn't)
Could we turn this into 'use the same reporting system as selinux'? It's absurd that they use different ones, you should merge them.
On 12/09/2010 06:10 PM, Adam Williamson wrote:
On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:
- Reporting to bugzilla without being able to scrape the bz username
and password out of the firefox credential store is just cruel.
- added as: "share bz credential with other apps"
- not sure if we can share the credentials with firefox, but we can
share it with apps that store it in the gnome-keyring (which ff doesn't)
Could we turn this into 'use the same reporting system as selinux'? It's absurd that they use different ones, you should merge them.
selinux uses the report package as a reporting back-end and we're planning (and working on..) to obsolete the report package by splitting ABRT reporting backed into a separate library so then ABRT and selinux will use the same reporting backend and thus they will store the settings in one place..
J.
On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:
- I really dislike that "local trace generation" and "retrace server"
are discussed as though they're the only options. If nothing else, for many non-trivial apps where abrt is potentially of the most use the core you're uploading can easily be hundreds of megabytes; that's not really better than downloading hundreds of megabytes. A network debuginfo service [1] would approach this problem in a completely different way, by letting the client download exactly as much debuginfo as it needs.
I mentioned the debuginfofs many times in ABRT flames, there was however a problem with our debug tools making it unusable, because one had to read the whole debuginfo file from the server and few other problems so that's why the retrace server idea came up. but this should fixed in the current tools so theoretically nothing prevents us from reviving it.. once this is done ABRT can easily use it...
I have trouble following what you're saying here. At what point does one need to "read the whole debuginfo file"?
- ajax
On 12/09/2010 07:46 PM, Adam Jackson wrote:
On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote:
- I really dislike that "local trace generation" and "retrace server"
are discussed as though they're the only options. If nothing else, for many non-trivial apps where abrt is potentially of the most use the core you're uploading can easily be hundreds of megabytes; that's not really better than downloading hundreds of megabytes. A network debuginfo service [1] would approach this problem in a completely different way, by letting the client download exactly as much debuginfo as it needs.
I mentioned the debuginfofs many times in ABRT flames, there was however a problem with our debug tools making it unusable, because one had to read the whole debuginfo file from the server and few other problems so that's why the retrace server idea came up. but this should fixed in the current tools so theoretically nothing prevents us from reviving it.. once this is done ABRT can easily use it...
I have trouble following what you're saying here. At what point does one need to "read the whole debuginfo file"?
I'm referring to this: https://fedorahosted.org/pipermail/crash-catcher/2010-September/000965.html
Jirka
On Thu, 09 Dec 2010 20:39:24 +0100, Jiri Moskovcak wrote:
On 12/09/2010 07:46 PM, Adam Jackson wrote:
I have trouble following what you're saying here. At what point does one need to "read the whole debuginfo file"?
I'm referring to this: https://fedorahosted.org/pipermail/crash-catcher/2010-September/000965.html
GDB on client side would need something like readonly NFS-like service to load the .debug files byte-wise. And this NFS-like service network protocol must be signed by Fedora project like the current rpms are.
Then the fast operation of GDB on the client depends on these known issues:
* http://fedoraproject.org/wiki/Features/GdbIndex which is now present in F14 updated packages (but it still was not present in F14 GA packages).
* Recheck THe .debug files reading via .gdb_index is really optimal for the network protocol.
* Fixing GDB to not ever touch .debug files for libraries not going to be used in the specific backtrace at all.
Regards, Jan
"Jan" == Jan Kratochvil jan.kratochvil@redhat.com writes:
Jan> GDB on client side would need something like readonly NFS-like Jan> service to load the .debug files byte-wise. And this NFS-like Jan> service network protocol must be signed by Fedora project like the Jan> current rpms are.
Jan> Then the fast operation of GDB on the client depends on these known Jan> issues:
Jan> * http://fedoraproject.org/wiki/Features/GdbIndex which is now Jan> present in F14 updated packages (but it still was not present in Jan> F14 GA packages).
Jan> * Recheck THe .debug files reading via .gdb_index is really Jan> optimal for the network protocol.
I assume it isn't. The core of the index is a memory-mapped hash table. GDB will access it in essentially random order.
Jan> * Fixing GDB to not ever touch .debug files for libraries not going to be Jan> used in the specific backtrace at all.
This seems like a good idea. Maybe GDB could detect that the debug info is remote and defer the reading only in this case.
Even if we don't read the debug info, we probably still want to read any python code associated with the library.
Another idea we could implement is do index queries over the net, say using a remote SQL server. This means more round trips, but less data to download. Maybe this isn't really the right tradeoff -- but the point is that we have a lot of leeway to change GDB, we don't have to try to work around it.
Tom
On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote: <snip>
- Reporting to bugzilla without being able to scrape the bz username
and password out of the firefox credential store is just cruel.
- added as: "share bz credential with other apps"
- not sure if we can share the credentials with firefox, but we can
share it with apps that store it in the gnome-keyring (which ff doesn't)
You don't really need the whole credentials, you can reuse the existing cookies from the store, as git-bz does (though you need to say which browser you used in the case of git-bz, but that can be worked around by actually reading the expiry date of the cookies).
On Thu, Dec 9, 2010 at 5:20 PM, Jiri Moskovcak jmoskovc@redhat.com wrote:
Gathering the RFEs at: https://fedorahosted.org/abrt/wiki/Wishlist
Is it true report plugins are written in C++ ? if so, I'd love to RFE "python wrapper to the plugins API" so we can write plugins more easily
On 12/10/2010 04:27 PM, giallu@gmail.com wrote:
On Thu, Dec 9, 2010 at 5:20 PM, Jiri Moskovcakjmoskovc@redhat.com wrote:
Gathering the RFEs at: https://fedorahosted.org/abrt/wiki/Wishlist
Is it true report plugins are written in C++ ? if so, I'd love to RFE "python wrapper to the plugins API" so we can write plugins more easily
It's true for the version in F14, but the version in git can use plugins written in whatever language you want as every plugin is an external app...
Adding my whishlist
1) /etc/abrt/conf.d/ directory - like httpd ones. So I can drop there configuration for my packages. For example when dovecot crashes, I'd like to see doveconf -n output
2) better notification for crashes. I have one application that crashes when I'm ending desktop session, but because abrt-gui is not running at that time (or it's just terminated when it shows up) I'm not notified about that crash and when I log in next time, nothing happens.
On 12/10/2010 09:24 AM, Michal Hlavinka wrote:
Adding my whishlist
- /etc/abrt/conf.d/ directory - like httpd ones. So I can drop there configuration for my packages. For example when dovecot crashes, I'd like to see doveconf -n output
- I can promise the /etc/abrt/conf.d/ only for blacklisting for the version we have in F14, but what you're asking here should be possible with the git version soon
- better notification for crashes. I have one application that crashes when I'm ending desktop session, but because abrt-gui is not running at that time (or it's just terminated when it shows up) I'm not notified about that crash and when I log in next time, nothing happens.
both added to https://fedorahosted.org/abrt/wiki/Wishlist
On Thu, 2010-12-09 at 10:51 -0500, Adam Jackson wrote:
- Reporting to bugzilla is a mistake.
Not discounting the idea, but just looking for more detail. What alternatives would you want to see? More kerneloops-like aggregate data collection, or something else?
Thanks, James
On Mon, 2010-12-13 at 10:50 -0500, James Laska wrote:
On Thu, 2010-12-09 at 10:51 -0500, Adam Jackson wrote:
- Reporting to bugzilla is a mistake.
Not discounting the idea, but just looking for more detail. What alternatives would you want to see? More kerneloops-like aggregate data collection, or something else?
Basically, yes. For a few reasons:
- Crash analysis requires more semantic knowledge of the content of the report than bugzilla is really designed for. I can have 17 reports with different backtraces all in different applications, but where the bug is "this exclusive section in this library is being called without the lock held". It's not reasonable to expect to add that kind of content awareness to bugzilla, and doing it from bz clients is clumsy at best.
- Bugzilla forces you to frame the discussion in terms of a component. That's probably right for applications. It's usually wrong for libraries, drivers, servers, or kernels. You want to start from the report as a gestalt, and not assign blame to a component until you actually know what's going on. (This is a condemnation of bugzilla in general, but it's made worse by the next point.)
- Separating machine-generated content from human-generated content is valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain.
- ajax
- Separating machine-generated content from human-generated content is
valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain.
Good point.
ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red "warning" sign for every unreported crash, green "you did good thing" sign for reported ones.
The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting.
It aslo makes sense to allow sending mostly machine-generated, few click "crash" reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now.
Karel
On 12/14/2010 02:54 PM, Karel Klic wrote:
- Separating machine-generated content from human-generated content is
valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain.
Good point.
ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red "warning" sign for every unreported crash, green "you did good thing" sign for reported ones.
The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting.
- btw, we tried that with making the howto field mandatory and I already saw some reports saying "I don't have a damn clue how to reproduce it, but this stupid ABRT thing won't let me continue" :))
It aslo makes sense to allow sending mostly machine-generated, few click "crash" reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now.
Karel
The problem is, that with ABRT we probably get more people involved in reporting bugs - which I think is great (would be a nice statistic to see if/how the number of new accounts has grown since ABRT) but unlike the older reporters with a good habits these new reporters won't create a good report using neither bz or ABRT... so yes, we need to change the UI to treat the reporters as they (the reporter rookies) deserve.. ABRT GUI should be more like "Assisted Bug Reporting for Dummies" :)) -> ABRD :)
J.
On Tuesday, December 14, 2010 03:19:32 pm Jiri Moskovcak wrote:
On 12/14/2010 02:54 PM, Karel Klic wrote:
- Separating machine-generated content from human-generated content is
valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain.
Good point.
ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red "warning" sign for every unreported crash, green "you did good thing" sign for reported ones.
The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting.
- btw, we tried that with making the howto field mandatory and I already
saw some reports saying "I don't have a damn clue how to reproduce it, but this stupid ABRT thing won't let me continue" :))
Educate people that such bug report is just useless as usually it is.
R.
It aslo makes sense to allow sending mostly machine-generated, few click "crash" reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now.
Karel
The problem is, that with ABRT we probably get more people involved in reporting bugs - which I think is great (would be a nice statistic to see if/how the number of new accounts has grown since ABRT) but unlike the older reporters with a good habits these new reporters won't create a good report using neither bz or ABRT... so yes, we need to change the UI to treat the reporters as they (the reporter rookies) deserve.. ABRT GUI should be more like "Assisted Bug Reporting for Dummies" :)) -> ABRD :)
J.
On 12/14/2010 05:14 PM, Jaroslav Reznik wrote:
On Tuesday, December 14, 2010 03:19:32 pm Jiri Moskovcak wrote:
On 12/14/2010 02:54 PM, Karel Klic wrote:
- Separating machine-generated content from human-generated content is
valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain.
Good point.
ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red "warning" sign for every unreported crash, green "you did good thing" sign for reported ones.
The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting.
- btw, we tried that with making the howto field mandatory and I already
saw some reports saying "I don't have a damn clue how to reproduce it, but this stupid ABRT thing won't let me continue" :))
Educate people that such bug report is just useless as usually it is.
How? Maybe I just don't understand, but if there is a way how to autodetect that the user input is useless then we'll add it, but analyse the text and try to guess if it's useless or not is really not trivial...
J.
R.
It aslo makes sense to allow sending mostly machine-generated, few click "crash" reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now.
Karel
The problem is, that with ABRT we probably get more people involved in reporting bugs - which I think is great (would be a nice statistic to see if/how the number of new accounts has grown since ABRT) but unlike the older reporters with a good habits these new reporters won't create a good report using neither bz or ABRT... so yes, we need to change the UI to treat the reporters as they (the reporter rookies) deserve.. ABRT GUI should be more like "Assisted Bug Reporting for Dummies" :)) -> ABRD :)
J.
On Thu, 09.12.10 10:51, Adam Jackson (ajax@redhat.com) wrote:
Here's some of my pet irritations with abrt. Feel free to add your own, but please keep the gratuitous "me too"ing to a minimum.
Here is my feature request:
I want some kind of D-Bus interface which I can use to hook up "systemctl status" with abrt, so that we can somehow refer to specific crash dumps in case systemd recieved SIGSEG/SIGABRT for a specific service.
(I discussed this a couple of times with ABRT folks, but to my knowledge nothing ever happened in this area)
Lennart
On 12/22/2010 11:29 AM, Lennart Poettering wrote:
On Thu, 09.12.10 10:51, Adam Jackson (ajax@redhat.com) wrote:
Here's some of my pet irritations with abrt. Feel free to add your own, but please keep the gratuitous "me too"ing to a minimum.
Here is my feature request:
I want some kind of D-Bus interface which I can use to hook up "systemctl status" with abrt, so that we can somehow refer to specific crash dumps in case systemd recieved SIGSEG/SIGABRT for a specific service.
(I discussed this a couple of times with ABRT folks, but to my knowledge nothing ever happened in this area)
Hi Lennart, I remember it and it's in our TODO list, but has a low priority, so that's why it's taking so long and we can prioritize this if needed. Btw, ABRT has a dbus interface, but probably not flexible enough to use with systemctl - it can give you the list of all crashes and then you would have to search for the specific crash "manually" and it doesn't provide an introspection, so you would have to either read the code or I can send you API description. And since systemctl is the only application which wants to use it you can send me your idea of how exactly you imagine to call it from systemctl and I can work on it during Christmas holiday and make the API according to your idea..
Jirka
On Wed, 22.12.10 12:25, Jiri Moskovcak (jmoskovc@redhat.com) wrote:
Hi Lennart, I remember it and it's in our TODO list, but has a low priority, so that's why it's taking so long and we can prioritize this if needed. Btw, ABRT has a dbus interface, but probably not flexible enough to use with systemctl - it can give you the list of all crashes and then you would have to search for the specific crash "manually" and it doesn't provide an introspection, so you would have to either read the code or I can send you API description. And since systemctl is the only application which wants to use it you can send me your idea of how exactly you imagine to call it from systemctl and I can work on it during Christmas holiday and make the API according to your idea..
Basically, what I want is something that I can use to find the abrt crash dump for a specific SIGCHLD signal systemd gets delivered due to a service coredumping. The D-Bus lookup function I'd like to call hence should have as parameters the PID plus the starttime of the process (which is probably better than the PID plus the crash timestamp, which necessarily would be inaccurate, but I guess would work too), which together should be a reasonably unique way to identify a process. This function should then return to me information about the crash which can be used to find the way from systemctl to the abrt crash dump viewer (for example, I'd be happy if you could suggest a way how to construct a command line from these parameters which can be used to open the graphical abrt viewer for the crash dump -- (is there even a text-only way to introspect crash dumps?)
Lennart