GNU bug report logs - #32458
SDL SEGFAULTs on foreign distro

Previous Next

Full log

Message #35 received at 32458 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Tim Gesthuizen <tim.gesthuizen <at> yahoo.de>, 32458 <at> debbugs.gnu.org
Subject: Re: bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)
Date: Mon, 15 Oct 2018 21:19:09 +0200

[Message part 1 (text/plain, inline)]

Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:

> On 22.08.2018, Tim Gesthuizen wrote:
>> This bisect passed without a single skip. It reports that the bug was
>> first introduced by 5318b103ff277efbac248a066d162589a9083baa (which is
>> the first commit after a larger merge).
>
> Maybe you missed that mail. The problem is that reverting the commit
> does not solve the bug on the current master branch. So I am searching
> for a good way of finding another bug through bisecting. This would mean
> that I would need to apply a patch of some form to make sure that the
> libepoxy problem is fixed before running the bisect script again.
> This is why I tried to rebase the master branch to not include commits
> updating libepoxy.

Oh, I see!  Sorry for the confusion.

One thing you can try to narrow down the search space is to try
reverting that commit at different points in the repository.

For example, I believe 5318b103f was merged in 49b6dc2b4.  If reverting
on top of 49b6dc2b4 does not work, it means the (other) problem was
introduced somewhere between 5318b103f^..49b6dc2b4.

For starters, can you try to revert 49b6dc2b4 on top of 0d6f84aab and
e0c9aed82?  My gut feeling says the first should work and the second
not :-)

> I hope my problem is more clear now. Maybe there is another way that is
> just too obvious and simple. If you don't have a good idea on how to do
> it, I will do the bisect again and do an input rewriting for the package
> I am building to use the old libepoxy and not the one of that revision.
> This will probably involve tons of package rebuilding so I am open for
> other approaches.

Input rewriting seems like a great workaround, however tedious.  It
would be good to provide better tooling for these kinds of cases (maybe
even "guix bisect").

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.