On Fri, Feb 16, 2018 at 03:04:11PM +0100, Jan Kratochvil wrote: > 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). Did it ever meet this goal? I never quite understood how it works, being far from this field, so I'm happy to be enlighten on the topic. > 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). Would you know if anyone in your old team would be interested by this? I'm trying to assess if there is actually an interest for it. You said you were interested by it but aren't working on this topic anymore, I don't think anybody else than you noticed it not working over the course of last year. So I wonder if we shouldn't just call it a day, provide a dump of the DB somewhere for people interested and decommission the app. Fixing it on the other hand would require someone learning how the code works, probably trying to poke at Kushal for inputs (but I don't want to assume he'll fix it as I'm assuming he has other priorities) and finish deploying that new version. It may not be quick. Thoughts? Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
