On Fri, Jul 13, 2018, 12:51 AM Petter Reinholdtsen <[email protected]> wrote:
> [Phil Miller] > > I was also seeing isenkramd occupying huge and growing amounts of memory, > > increasing by several megabytes with each time a device was plugged in > (in > > my case, when my monitor was turned on and its USB hub attached devices > > came back). > > Thank you for getting in touch. It is always good to hear from users, > as some times I wonder if I am the only one finding isenkram useful. :) > I haven't really gotten to experience using it as yet, some I haven't used any new hardware in quite a while. I saw that it was installed by default (or through some dependency), so I figured it was worth fixing rather than ripping out. > > I tracked this down to a leak in the appstream library, for which I > > submitted a patch upstream that's now been merged. We're just waiting > > on a new release of that and an upload to Debian, and this will be > > fixed. > > Thank you very much for finding and fixing these leaks. Do you by any > chance know which function calls in the isenkram code triggered these > leaks? I am considering if it is useful to implement a workaround while > we wait for upstreams changes to make it into the various Debian > releases. > I didn't record the stack traces from valgrind in the commit messages as I should have. I don't think a workaround would be worthwhile. Matthias is both upstream and Debian package maintainer of appstream. We just need to convince him to tag and upload. Or, if you're feeling really proactive and he's otherwise occupied, NMU appstream with the patches. There's pretty much nothing else changed upstream, so it would be quite easy. >
