Wednesday Triage Report (2020-09-23)

[Sergio Durigan Junior]

On Thursday, September 24 2020, Bryce Harrington wrote:

> On Wed, Sep 23, 2020 at 11:05:50PM -0400, Sergio Durigan Junior wrote:
>> Hi,
>> 
>> This Wednesday I did my first triage, replacing Rafael.
>> 
>> The only noteworthy bug I have is this one:
>> 
>> - https://pad.lv/1676328 - *(Confirmed) [sssd] - sssd_be is leaking
>>   memory
>> 
>> There has been a comment by yet another person confirming the bug.  This
>> is obviously not server-next, but I don't have anything meaningful to
>> reply to the user for now.  Andreas, you mentioned in the bug that you
>> were going to look at the changes in 1.16 and see if anything comes up;
>> do you remember doing that?  I know it's been a while, but...
>
> The confirmation isn't really adding new info to the bug that would help
> move it forward.  (Indeed, the bug was never really pinpointed down to a
> specific test case or root cause - who knows if the drive-by me-too is
> seeing the "same" memory leak or some other bug that also leaks.)  So,
> the bug probably doesn't really need a status update from us - if we
> don't have any new info a reply could just be more noise.

Thanks for the detailed reply, Bryce.

So, the reason I thought this bug deserved to be mentioned is because,
IIUC, the ball is (at least partially) in our court.  It seems to me
that Andreas was investigating it and that we aren't waiting on input
from the users at me moment, although, as you said below, the bug is
hard to reproduce and fix.

> However, if you're feeling generous one thing I sometimes do with this
> sort of bug is think about what the next action would be to move it
> forward in its lifecycle.  "If you'd like to help move this bug forward,
> it looks to me like it is currently blocked because ______."

Right.  I thought about that, but it seemed best to ping Andreas first,
just in case there is some progress that I'm unaware of.

> From the linked bug report it says the issue was in 1.13.4 but resolved
> in 1.13.5 (git) as tested on 2016-11-30.  There was never actually a
> 1.13.5 release, but there are commits in the upstream 'sssd-1.13' branch
> after 1.13.4 was tagged.  So, a brute force git bisection search between
> the 1.13.4 tag and sssd-1.13's tip might discover the solution.
>
>   https://github.com/SSSD/sssd/commits/sssd-1-13?after=c7636e4721cb52f1b36bf93a3f27a247f3f9231f+270&branch=sssd-1-13
>
>
> Bugs that take a long time to reproduce can be a PITA to git bisect
> though, and it's certainly possible the leak requires more than a single
> leak fix.  Looking through the git tree I spot a number of leak fixes,
> e.g. just from a few months after the release:
>
> https://github.com/SSSD/sssd/commit/e22cbe9326073e6d42fe2118661fa6daaed8638c
> https://github.com/SSSD/sssd/commit/2fb750062a665dbf318b5ffb2e53f1060e43b8dc
> https://github.com/SSSD/sssd/commit/312d211e03b9f3769a0362f1767cc59792e32746
>
> So another approach might be to just blindly cherrypick anything between
> 1.13.4 and 2016-11-30 11:31:50 mentioning "memory" or "leak" and throw them
> in a package and stick it in a ppa for testing.  But this is now more
> into bug-work than triaging, and without a reliable test case to
> reproduce it, it's just stabbing in the dark.

Good advice.  IIUC, that's kind of what Andreas tried to do in the PPA
he mentioned.

Thanks for taking the time to better explain the process!

Cheers,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14