Bug#820416: kodi: FTBFS in testing (Segmentation fault)

[Bálint Réczey]

Hi Santiago,

2016-08-24 17:36 GMT+02:00 Santiago Vila <sanvila at unex.es>:
> Hi.
>
> Any progress on this? This is still reproducible. I'm attaching a
> build log for the version which has just entered testing.

I have uploaded a new version to experimental with two related changes.

One is not failing the build when the test fails. This is not nice,
but the tests
were completely broken while kodi ran fine on my test system.

The second is running the tests with Valgrind when it is installed to have
better chance at finding allocation errors. I also proposed the change at
upstream listing an error which could mess up mutex handling:
https://github.com/xbmc/xbmc/pull/10334

>
> On Sun, 17 Apr 2016, Balint Reczey wrote:
>
>> It suggests there is something wrong with the mutex handling and TSAN seems to confirm that:
>> [...]
>> I need to test if the problem still exists in upstream master and verify if
>> it is not a false positive TSAN warning and the root cause is indeed here.
>
> Could you translate that into a language that a non-programmer
> could understand?
>
>> I'm setting the bug's severity to normal because while it is reproducible
>> the FTBFS does not happen on Debian's buildds [...]
>
> Hmm. I'm not going to enter into a severity war, but you should be
> aware that the theory that a FTBFS is not RC because "it does not
> happen" in Debian's buildds has many flaws.
>
> For example, for a package which FTBFS randomly, it is completely
> useless, as a successful build just means that we were lucky that
> time.

I'm trying to apply definitions from here:
https://www.debian.org/Bugs/Developer#severities

I don't like having this bug, but if a program fails to build 50% of
the time but runs fine it can be released IMO since users are not
affected.

>
> We should better not care too much about what happened in the
> autobuilders the last time it was tried, we should care more about
> what could happen the next time.
>
> I'm using sbuild and the autobuilders are using sbuild as well
> (or a variant of it).
>
> If you think this may not happen in official autobuilders, could you
> please explain why?

I don't think that it may not happen, but I say that it did not seem to
happen so far which makes me think it won't happen often and when
it happens autobuilders will try again anyway.

I understand that having this issue is painful for people like you doing the
hard work of rebuilding many packages and I'm trying to help.

Starting with 17.x the tests won't make the build fail until they run
reliably thus
you'll be able to rebuild kodi. Valgrind will also help upstream in catching
bugs earlier.

>
> (Because my machine does not have enough memory? How would I know that
> in advance when we don't have a Build-Memory control field?)
>
>> thus does not prevent rebuilding the package when needed.
>
> It does prevent me from rebuilding the package, which makes the
> software non-free for me and apparently anybody who does not have a
> machine with 32 GB of RAM (which is still a lot of people).

I guess you can build it with "DEB_BUILD_OPTIONS=nocheck", thus
this seems to be a bit of exaggeration.

>
> I would say that would deserve important severity at least.

I think the bug does not fit "important"'s definition [1] but feel free
to raise it.
I agree with you on this bug being valid and needs to be fixed
no matter what the severity is.

Cheers,
Balint

>
> (I said 32 GB just as an example, but if that's a more or less
> accurate summary of this bug, I'd like to know the exact figure).
>
> Thanks.


[1] "important: a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone."