GNU bug report logs -
#32458
SDL SEGFAULTs on foreign distro
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32458 in the body.
You can then email your comments to 32458 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Thu, 16 Aug 2018 17:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Thu, 16 Aug 2018 17:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
since a few days now SDL2 and SDL-1.2 are broken for me through Guix.
Running any kind of application that uses SDLs rendering mechanisms
crashes immediately while initializing window and renderer.
I tried tracking down the bug using GDB and found out that the bug
occurs while compiling/loading the shader code in my local graphics driver.
An invocation of memcpy causes a SEGFAULT during this operation.
I am running Guix on top of Debian Stretch with the radeon graphics driver.
I suspect binary incompatibility between Guix and Debians compiler to be
the cause of this problem but I cannot verify anything.
You find a log of my gdb session which includes some stacktraces from
where the program crashed.
If you need more information about my setup or technical details feel
free to ask.
I also want to note that SDL-1.2 definitely worked for me a few weeks
ago through Guix.
Sincerely,
Tim Gesthuizen
[gdb.log (text/x-log, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 20 Aug 2018 16:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I tried to bisect the bug by building Guix from git.
You find the script I used as well as some information about the bisect
attached (full log is 17MB so I copied the most important things).
[test.sh (application/x-shellscript, attachment)]
[guix-sdl-bisect (text/plain, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 20 Aug 2018 20:36:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Tim,
Thanks a lot for this debugging work!
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> I tried to bisect the bug by building Guix from git.
> You find the script I used as well as some information about the bisect
> attached (full log is 17MB so I copied the most important things).
[...]
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
[...]
> We cannot bisect more!
> bisect run cannot continue any more
>
> Bisect Rest (31)
We had a private conversation about this on IRC and I think the reason
you had to skip these commits were because of ABI issues in the git
checkout (incompatible Guile objects).
Current Guix actually warns about it and tells you what to do (very
nice!), but that does not work when bisecting this deep :-)
The surefire approach is to run "make clean-go". That will almost
certainly get Guix building again, but you also have to compile all the
Scheme code anew. You could first try something along the lines of
"rm gnu/{services,system,tests}{,/}*.go && make" to save (or waste :-P)
a little time.
Hope this helps! I think we are almost there. :-)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 20 Aug 2018 21:01:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello again,
Just a quick feedback on the bisect script:
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> #!/bin/sh
>
> cd $HOME/src/guix/build
> (cd ..; ./bootstrap) || exit 125
> (../configure --localstatedir=/var && make -j8) || exit 125
> PATH=$(./pre-inst-env guix build teeworlds | grep /gnu/store | tail -n 1) || exit 125
> $PATH/bin/teeworlds || exit 1
I suggest not running "./bootstrap" and "./configure" in between runs.
"make" will invoke ./configure (with current parameters) if necessary.
Then it can be reduced to a two-liner:
[test.sh (application/x-sh, inline)]
[Message part 3 (text/plain, inline)]
Again, nice work; I look forward to fix this bug :-)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Wed, 22 Aug 2018 19:20:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 20.08.2018 22:59, Marius Bakke wrote:
> Hello again,
>
> Just a quick feedback on the bisect script:
>
> Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
>
>> #!/bin/sh
>>
>> cd $HOME/src/guix/build
>> (cd ..; ./bootstrap) || exit 125
>> (../configure --localstatedir=/var && make -j8) || exit 125
>> PATH=$(./pre-inst-env guix build teeworlds | grep /gnu/store | tail -n 1) || exit 125
>> $PATH/bin/teeworlds || exit 1
>
> I suggest not running "./bootstrap" and "./configure" in between runs.
> "make" will invoke ./configure (with current parameters) if necessary.
>
> Then it can be reduced to a two-liner:
>
>
>
>
> Again, nice work; I look forward to fix this bug :-)
>
I have changed the bisect script.
You find the new one attached. I have never worked with autoconf so I
just wanted to be sure that everything would configure correctly and not
cause problems.
> I think the reason
> you had to skip these commits were because of ABI issues in the git
> checkout (incompatible Guile objects).
Well, I also somewhat forgot that I fixed teeworlds not a long time ago
(see commit e402a66b07c12aadf5eed1472110684831f1f498)... so any
compilations of teeworlds before were doomed to fail.
This is not as bad as it sounds because remembering this gave me a
commit that I could definitely verify as good.
With this new starting point I started bisecting again from that commit
marked as the first good one to the current commit on master marked as
the first bad one.
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).
I also noticed something odd: After I realized that using teeworlds for
verifying SDL could not have been a very wise decision I wrote a little
guile script using guile-sdl2 (sdl.scm).
I tried to bisect using this script for SDL verification and found out
that I could not find any commits where SDL2 worked for me.
Even in commits where teeworlds builds and runs without a problem SDL2
will always crash.
Also there are some revisions where teeworlds starts with bad resolution
(the window begins on my second monitor and ends somewhere on my first
monitor). But that is probably not of interest now.
I hope these informations help. If I forgot something in the rush of
writing this mail feel free to ask for it.
[test.sh (application/x-shellscript, attachment)]
[sdl.scm (text/x-scheme, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Sun, 07 Oct 2018 16:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I tried to find some free time to investigate a little bit further in
what exactly triggers the crash to happen.
A few days ago I had the idea of getting a GL context through GLUT and
don't use SDL at all. So I quickly investigated whether this would also
crash.
So I fetched the cube example (cube.c) from the OpenGL example archive:
https://www.opengl.org/archives/resources/code/samples/glut_examples/examples/examples.html
and compiled it through guix. You can find the exact procedure by
inspecting the log attached. If I did not make an error this should
proof that the problem lies in OpenGL and not in SDL.
Tim.
[log.txt (text/plain, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Sun, 07 Oct 2018 20:07:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello! Sorry for dropping the ball on this.
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> Hi,
> I tried to find some free time to investigate a little bit further in
> what exactly triggers the crash to happen.
> A few days ago I had the idea of getting a GL context through GLUT and
> don't use SDL at all. So I quickly investigated whether this would also
> crash.
> So I fetched the cube example (cube.c) from the OpenGL example archive:
>
> https://www.opengl.org/archives/resources/code/samples/glut_examples/examples/examples.html
>
> and compiled it through guix. You can find the exact procedure by
> inspecting the log attached. If I did not make an error this should
> proof that the problem lies in OpenGL and not in SDL.
>
> Tim.
> tibbe <at> tibbe-pc:~/src/glut-example$ guix environment --ad-hoc freeglut
> tibbe <at> tibbe-pc:~/src/glut-example$ echo $GUIX_ENVIRONMENT
> /gnu/store/gsfq0h6hpjz9ddvgn4g3gkl5r6gg3ink-profile
> tibbe <at> tibbe-pc:~/src/glut-example$ ls $GUIX_ENVIRONMENT
> etc include lib manifest share
> tibbe <at> tibbe-pc:~/src/glut-example$ gcc cube.c -L $GUIX_ENVIRONMENT/lib -l glut -l GL -I $GUIX_ENVIRONMENT/include
> /tmp/ccXMXGNS.o: In function `init':
> cube.c:(.text+0x321): undefined reference to `gluPerspective'
> cube.c:(.text+0x372): undefined reference to `gluLookAt'
> collect2: error: ld returned 1 exit status
> tibbe <at> tibbe-pc:~/src/glut-example$ gcc cube.c -L $GUIX_ENVIRONMENT/lib -l glut -l glu -l GL -I $GUIX_ENVIRONMENT/include
> ld: cannot find -lglu
> collect2: error: ld returned 1 exit status
> tibbe <at> tibbe-pc:~/src/glut-example$ gcc cube.c -L $GUIX_ENVIRONMENT/lib -l glut -l GLU -l GL -I $GUIX_ENVIRONMENT/include
> tibbe <at> tibbe-pc:~/src/glut-example$ ls
> a.out cube.c
> tibbe <at> tibbe-pc:~/src/glut-example$ ./a.out
> Segmentation fault
Nice catch! Earlier in the bisect, you found
5318b103ff277efbac248a066d162589a9083baa (gnu: libepoxy: Update to
1.5.1.). Can you try this patch and see if it makes a difference?
[0001-gnu-libepoxy-Downgrade-to-1.5.0.patch (text/x-patch, inline)]
From 2fa87c8c06b0a20e1f6c5c4e9edcc6a6fdd0c3d1 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke <at> fastmail.com>
Date: Sun, 7 Oct 2018 22:04:27 +0200
Subject: [PATCH] gnu: libepoxy: Downgrade to 1.5.0.
This reverts commit 5318b103ff277efbac248a066d162589a9083baa.
---
gnu/packages/gl.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index b88fab492..d512f10f7 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -550,7 +550,7 @@ OpenGL graphics API.")
(define-public libepoxy
(package
(name "libepoxy")
- (version "1.5.2")
+ (version "1.5.0")
(source (origin
(method url-fetch)
(uri (string-append
@@ -558,7 +558,7 @@ OpenGL graphics API.")
version "/libepoxy-" version ".tar.xz"))
(sha256
(base32
- "1n57xj5i6giw4mp5s59w1m9bm33sd6gjg7r00dzzvcwya6326mm9"))))
+ "1md58amxyp34yjnw4xa185hw5jm0hnb2xnhdc28zdsx6k19rk52c"))))
(arguments
`(#:phases
(modify-phases %standard-phases
--
2.19.0
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 08 Oct 2018 18:08:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07.10.2018 22:06, Marius Bakke wrote:
> Hello! Sorry for dropping the ball on this.
No problem. Nobody pressures you to help others :)
> Nice catch! Earlier in the bisect, you found
> 5318b103ff277efbac248a066d162589a9083baa (gnu: libepoxy: Update to
> 1.5.1.). Can you try this patch and see if it makes a difference?
I also noticed this and reverted the commit introducing the bug. After
reverting the commit I still got a broken OpenGL in `master`. Right now
I am trying to rebase the current master branch to not include the two
commits updating libepoxy in order to bisect that branch again to find
the thing that keeps simple reverting from working.
This really takes some time as it brings every merge-conflict ever since
back to life and I have to resolve them.
I hope that I will not introduce new bugs during rebasing and find the
time to get the rebase and the bisect going and report the other cause
of failure.
Tim.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 08 Oct 2018 18:29:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> On 07.10.2018 22:06, Marius Bakke wrote:
>> Hello! Sorry for dropping the ball on this.
>
> No problem. Nobody pressures you to help others :)
>
>> Nice catch! Earlier in the bisect, you found
>> 5318b103ff277efbac248a066d162589a9083baa (gnu: libepoxy: Update to
>> 1.5.1.). Can you try this patch and see if it makes a difference?
>
> I also noticed this and reverted the commit introducing the bug. After
> reverting the commit I still got a broken OpenGL in `master`. Right now
> I am trying to rebase the current master branch to not include the two
> commits updating libepoxy in order to bisect that branch again to find
> the thing that keeps simple reverting from working.
> This really takes some time as it brings every merge-conflict ever since
> back to life and I have to resolve them.
> I hope that I will not introduce new bugs during rebasing and find the
> time to get the rebase and the bisect going and report the other cause
> of failure.
If reverting did not help, I doubt rebasing it away will do a
difference. It also sounds very tedious!
Have you been able to find a commit that definitely works? Say,
0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a
good test case, it should be easier to script the bisect (just make sure
to invoke "make clean && make" between runs to avoid ABI issues).
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Wed, 10 Oct 2018 15:36:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 08.10.2018 20:28, Marius Bakke wrote:
> If reverting did not help, I doubt rebasing it away will do a
> difference. It also sounds very tedious!
I stopped rebasing. It was too tedious.
> Have you been able to find a commit that definitely works? Say,
> 0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a
I could verify that this commit also works.
> 0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a
> good test case, it should be easier to script the bisect (just make sure
> to invoke "make clean && make" between runs to avoid ABI issues).
But I have bisected already :)
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.
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.
Tim.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 15 Oct 2018 19:20:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 15 Oct 2018 19:32:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Marius Bakke <mbakke <at> fastmail.com> writes:
> 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 :-)
Sorry, I meant "revert 5318b103f" here. But it does not make sense for
0d6f84aab, since it's not there! It would be good to test it though,
since it comes from a 'core-updates' merge around the same time.
If 0d6f84aab works, good candidates to try next is reverting 5318b103f
on top of 0d6f84aab, 9a1f92a6e, and faccae1c3.
Hope this helps, and thanks for your patience here!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Tue, 16 Oct 2018 18:21:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I tried to bisect again using the input rewriting method. You find the
two scripts for this attached. It turned out that this does not only
take a lot of time for building single versions of guix and the modified
teeworlds package, but it also brings up the bug with the missing
pkg-config package in the package definition of teeworlds. Because of
this I stopped trying to bisect with the input rewritten versions of the
packages and tried reverting as you suggested.
Reverting on top of 0d6f84aab, guix and packages using OpenGL build, but
still segfaults on initialization. I hope you have another good idea, as
bisecting with the above method would probably take a lot of time.
Tim.
[check.sh (application/x-shellscript, attachment)]
[fixed-teeworlds.scm (text/x-scheme, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Wed, 17 Oct 2018 15:14:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 32458 <at> debbugs.gnu.org (full text, mbox):
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> Hi,
> I tried to bisect again using the input rewriting method. You find the
> two scripts for this attached. It turned out that this does not only
> take a lot of time for building single versions of guix and the modified
> teeworlds package, but it also brings up the bug with the missing
> pkg-config package in the package definition of teeworlds. Because of
> this I stopped trying to bisect with the input rewritten versions of the
> packages and tried reverting as you suggested.
OK! Thanks for testing. I wonder if can make that cheaper somehow.
> Reverting on top of 0d6f84aab, guix and packages using OpenGL build, but
> still segfaults on initialization. I hope you have another good idea, as
> bisecting with the above method would probably take a lot of time.
Are you saying that you can trigger the bug on top of commit 0d6f84aab?
That is interesting, since it does not contain the libepoxy update and
should be a good candidate for a "normal" bisect. Can you try to "git
bisect bad" and then try these commits:
6449e68d350b8196d39715a2e775337c7c93387e
263c9941a1e523b360ca9f42d1ed6b11e6e6e285
If any of them are good, just follow git bisect instructions. I believe
the second should be good, and possibly the first too.
[...]
> (use-modules (gnu packages)
> (gnu packages games)
> (gnu packages gl)
> (guix packages)
> (guix profiles))
>
> (define libepoxy-legacy
> (package
> (inherit libepoxy)
> (version "1.4.0")))
This package is missing a (source ...) field. So this only pretends to
be 1.4.0, but is actually the same as the inherited one.
(Also, should it not be 1.5.0?)
>
> (define with-libepoxy-legacy
> (package-input-rewriting (list (cons libepoxy libepoxy-legacy))))
>
> (define teeworlds-fixed
> (with-libepoxy-legacy teeworlds))
>
> (packages->manifest (list teeworlds-fixed))
Thanks for sharing these scripts!
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 22 Oct 2018 17:24:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I did another bisect to find the second cause of failure.
I used the input rewriting technique but with the fixed libepoxy definition:
>> (use-modules (gnu packages)
>> (gnu packages games)
>> (gnu packages gl)
>> (guix packages)
>> (guix profiles))
>>
>> (define libepoxy-legacy
>> (package
>> (inherit libepoxy)
>> (version "1.4.0")))
>
> This package is missing a (source ...) field. So this only pretends to
> be 1.4.0, but is actually the same as the inherited one.
>
> (Also, should it not be 1.5.0?)
Yes it should be. Something made me think the expression evaluating to
the origin object in the original libepoxy definition would be
reevaluated. And it also should be 1.5.0.
I started using the small guile script using guile-sdl2 again, simply
because I do not need to close the window manually if a commit is good
and the program starts. Otherwise the bisect would still need human
input. You can find the scripts that I used attached as a tar archive.
It has some hardcoded paths though. Execute the check.sh script to check
the current commit.
After a really long bisect and tons of package rebuilding git found
commit faccae1c3769c90694c2b7eee0e4e9ab53049a8f to be guilty. The commit
updates mesa so it seems quite possible.
I don't have that much time right now but I will try to revert the two
commits found so far and see whether this gets OpenGL running again on
the master branch.
Tim.
[debug-scripts.tar.gz (application/gzip, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 22 Oct 2018 20:51:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Tim!
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> Hi,
> I did another bisect to find the second cause of failure.
> I used the input rewriting technique but with the fixed libepoxy definition:
>
>>> (use-modules (gnu packages)
>>> (gnu packages games)
>>> (gnu packages gl)
>>> (guix packages)
>>> (guix profiles))
>>>
>>> (define libepoxy-legacy
>>> (package
>>> (inherit libepoxy)
>>> (version "1.4.0")))
>>
>> This package is missing a (source ...) field. So this only pretends to
>> be 1.4.0, but is actually the same as the inherited one.
>>
>> (Also, should it not be 1.5.0?)
>
> Yes it should be. Something made me think the expression evaluating to
> the origin object in the original libepoxy definition would be
> reevaluated. And it also should be 1.5.0.
>
> I started using the small guile script using guile-sdl2 again, simply
> because I do not need to close the window manually if a commit is good
> and the program starts. Otherwise the bisect would still need human
> input. You can find the scripts that I used attached as a tar archive.
> It has some hardcoded paths though. Execute the check.sh script to check
> the current commit.
> After a really long bisect and tons of package rebuilding git found
> commit faccae1c3769c90694c2b7eee0e4e9ab53049a8f to be guilty. The commit
> updates mesa so it seems quite possible.
Woohoo, congrats! Really great to finally nail this down.
One thing that might be worth a try before bisecting Mesa itself is
building against LLVM 3.9.1 again. I don't know the relevance of the
"exactly 3.9.1 for swrast" comment from that commit.
We should also check whether this problem is fixed in 18.2 (available in
the 'staging' branch).
Out of curiosity, which graphics driver are you using?
> I don't have that much time right now but I will try to revert the two
> commits found so far and see whether this gets OpenGL running again on
> the master branch.
Great, thank you!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Mon, 29 Oct 2018 18:44:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
On 22.10.2018 22:50, Marius Bakke wrote:
> One thing that might be worth a try before bisecting Mesa itself is
> building against LLVM 3.9.1 again. I don't know the relevance of the
> "exactly 3.9.1 for swrast" comment from that commit.
Just a quick update: I tried the following things and all of them failed
but in a little more helpful manor:
- Building current version of mesa with LLVM 3.9.1: mesa fails to
configure -> Some part needs at least LLVM version 4.
- Building old mesa with LLVM 3.9.1: unit tests in the testsuite of mesa
fail which causes the build to fail. I could not investigate the
failure yet but it seems quite promising.
> Out of curiosity, which graphics driver are you using?
The radeon driver with non free firmware, sadly :(
I cannot get anything free to run and I will switch to another computer
as my main computer soon. I hope I can find the cause for the bug before
I switch.
Tim.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Wed, 14 Nov 2018 19:50:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de> writes:
> Hi,
>
> On 22.10.2018 22:50, Marius Bakke wrote:
>> One thing that might be worth a try before bisecting Mesa itself is
>> building against LLVM 3.9.1 again. I don't know the relevance of the
>> "exactly 3.9.1 for swrast" comment from that commit.
>
> Just a quick update: I tried the following things and all of them failed
> but in a little more helpful manor:
>
> - Building current version of mesa with LLVM 3.9.1: mesa fails to
> configure -> Some part needs at least LLVM version 4.
> - Building old mesa with LLVM 3.9.1: unit tests in the testsuite of mesa
> fail which causes the build to fail. I could not investigate the
> failure yet but it seems quite promising.
OK, thanks for checking. I guess the next step is to bisect the
differences between Mesa 18.0.5 and 18.1.1.
You can use `guix build --with-source=/path/to/mesa/checkout mesa` in
order to use `git bisect` along with Guix.
>> Out of curiosity, which graphics driver are you using?
>
> The radeon driver with non free firmware, sadly :(
> I cannot get anything free to run and I will switch to another computer
> as my main computer soon. I hope I can find the cause for the bug before
> I switch.
Right. It would be great if someone could confirm this bug with another
supported driver. But I suppose a bisect will tell us the answer.
Thanks!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Fri, 18 Jan 2019 20:15:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (application/pgp-encrypted, inline)]
[Message part 2 (application/octet-stream, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32458
; Package
guix
.
(Wed, 23 Jan 2019 17:33:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 32458 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
So the machine that has this error has the following properties:
Distro: Debian Stretch
``` sources.list
deb http://ftp.de.debian.org/debian/ stretch main
deb-src http://ftp.de.debian.org/debian/ stretch main
deb http://security.debian.org/debian-security stretch/updates main
deb-src http://security.debian.org/debian-security stretch/updates main
# stretch-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ stretch-updates main
deb-src http://ftp.de.debian.org/debian/ stretch-updates main
```
Bug still apears after: `apt update && apt upgrade -y`
`uname -a` returns:
```
Linux <hostname> 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27)
x86_64 GNU/Linux
```
(I substituted the real hostname with <hostname>)
Loaded Xorg modules:
`grep LoadModule /var/log/Xorg.0.log`
```
[ 11.843] (II) LoadModule: "glx"
[ 11.856] (II) LoadModule: "ati"
[ 11.857] (II) LoadModule: "radeon"
[ 11.860] (II) LoadModule: "modesetting"
[ 11.861] (II) LoadModule: "fbdev"
[ 11.861] (II) LoadModule: "vesa"
[ 11.870] (II) LoadModule: "fbdevhw"
[ 11.872] (II) LoadModule: "fb"
[ 11.873] (II) LoadModule: "dri2"
[ 11.874] (II) LoadModule: "glamoregl"
[ 12.394] (II) LoadModule: "ramdac"
[ 12.705] (II) LoadModule: "libinput"
```
The bug still appears after pulling a new version of guix (e5ad2cdf1):
`guix environment --ad-hoc teeworlds -- teeworlds` for example
SEGFAULTs.
I hope this information helps reproducing the bug.
Tim.
[signature.asc (application/pgp-signature, attachment)]
bug closed, send any further explanations to
32458 <at> debbugs.gnu.org and Tim Gesthuizen <tim.gesthuizen <at> yahoo.de>
Request was from
Tim Gesthuizen <tim.gesthuizen <at> yahoo.de>
to
control <at> debbugs.gnu.org
.
(Wed, 23 Jan 2019 17:35:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 21 Feb 2019 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 157 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.