On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote: > So what do you advice as course of action here, should we fix darkserver or move > its functionality to ABRT? "move its functionality to ABRT" > The later is tempting to me if it's just a few lines of code added on an app we > already maintain. One problem of ABRT is that it cannot (or at least not easily) provide the core file to Bug Assignee. Users always fail to figure out how when I ask them for that. I do not know if it is just not user friendly enough or if the core files gets deleted from disk too quickly. And developers (that is me) could not use ABRT so far as it OOM-killed machine on a first segfaulted program: -fsanitize=address locks up abrt-hook-ccpp https://bugzilla.redhat.com/show_bug.cgi?id=1164548 It is EOLed again but maybe it works now on F-27 after my quick local re-check, I will check it later once I have access to an F-27 VM (travelling now). Then the ABRT bugreport does not contain build-ids of the shared libraries involved, only build-ids of frames from a backtrace ("core_backtrace") which is not sufficient to reproduce the same memory layout. It seems to me interactive crash core file analysis is just not a goal of ABRT (which is what was the goal of darkserver). And currently after my reassignment in Red Hat I currently do not have any ABRT bugreports to investigate so I am currently not involved in this darkserver/ABRT build-id crash reproducibility (I may be again later). Regards, Jan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
