Description of problem: alienarena-7.30-1.fc11.x86_64 crashes on startup. The previous version did not. Running from the command line gives [andre@compaq-pc ~]$ alienarena-wrapper added /usr/share/alienarena/data1 to search paths added /usr/lib64/alienarena/data1 to search paths added ./data1 to search paths using /home/andre/.codered/data1/ for writing added /home/andre/.codered/data1 to search paths added /usr/share/alienarena/arena to search paths added /usr/lib64/alienarena/arena to search paths using /home/andre/.codered/arena/ for writing added /home/andre/.codered/arena to search paths execing default.cfg couldn't exec config.cfg Console initialized. ------- sound initialization ------- Segmentation fault [andre@compaq-pc ~]$ My system is a fully updated clean install of x86_64 F11. Version-Release number of selected component (if applicable): alienarena-7.30-1.fc11.x86_64 How reproducible: always
Same on x86: alienarena-7.30-1.fc11.i586
I have the same behavior as before on an i686 machine with no sound devices currently plugged in. Running strace -o alienarena.txt -f alienarena-wrapper the last part of the output is 3623 write(3, "\n------- sound initialization ---"..., 38) = 38 3623 open("/usr/lib64/alienarena/arena/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 open("/etc/ld.so.cache", O_RDONLY) = 4 3623 fstat(4, {st_mode=S_IFREG|0644, st_size=148809, ...}) = 0 3623 mmap(NULL, 148809, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7feb30e95000 3623 close(4) = 0 3623 open("/lib64/tls/x86_64/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/lib64/tls/x86_64", 0x7fff993a0200) = -1 ENOENT (No such file or directory) 3623 open("/lib64/tls/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/lib64/tls", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 3623 open("/lib64/x86_64/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/lib64/x86_64", 0x7fff993a0200) = -1 ENOENT (No such file or directory) 3623 open("/lib64/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/lib64", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 3623 open("/usr/lib64/tls/x86_64/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/usr/lib64/tls/x86_64", 0x7fff993a0200) = -1 ENOENT (No such file or directory) 3623 open("/usr/lib64/tls/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/usr/lib64/tls", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 3623 open("/usr/lib64/x86_64/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/usr/lib64/x86_64", 0x7fff993a0200) = -1 ENOENT (No such file or directory) 3623 open("/usr/lib64/libopenal.so", O_RDONLY) = -1 ENOENT (No such file or directory) 3623 stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=126976, ...}) = 0 3623 munmap(0x7feb30e95000, 148809) = 0 3623 --- SIGSEGV (Segmentation fault) @ 0 (0) --- 3623 +++ killed by SIGSEGV +++ and it turns out that /usr/lib64/libopenal.so is owned by the openal-devel package. Installing this package allows alienarena to run with segfaulting. Should this be a dependency?
Sorry, I meant to say "without segfaulting".
Even though it runs without segfaulting if openal-devel is installed, there is no sound. Running alienarena-wrapper from the command line shows the following: ------- sound initialization ------- /usr/lib64/libopenal.so.0: undefined symbol: alSource3i /usr/lib64/libopenal.so.0: undefined symbol: alSourceiv /usr/lib64/libopenal.so.0: undefined symbol: alGetSource3i Sound failed: Unable to start OpenAL. Game will continue without sound.
Wow, okay, that's weird. I'll have to figure out what in the world is going on here... my primary hard disk just died on me, but I should be able to look into this in the next day or so.
This is a "me too" Fully patched FC11 system, I start alienarena and it segfaults. strace led me to take a punt and symlink /usr/lib/libopenal.so.0 to /usr/lib/libopenal.so That fixed the segfault, but (as above) I end up with "Game will continue without sound" Sounds like the alienarena binary was built against a different version of openal? I have openal-0.0.9-0.17.20060204cvs.fc11.i586 with alienarena-7.30-1.fc11 Jason
So, there are two problems here. 1. Alienarena tries to dlopen "libopenal.so", which only lives in openal-devel. It is easy enough to fix it to dlopen the proper library, which leads to problem 2: 2. Alienarena is expecting a much newer revision of openal than exists in Fedora. An updated openal (openal-soft) just went into rawhide, but it isn't in Fedora 10 or 11. In order for this package to work (and I've confirmed that it does work in rawhide with the newer openal-soft), we need openal-soft to be built and pushed as an update for Fedora 10 and 11. I've CC'd the openal and openal-soft maintainers (and Hans, just for good measure), who will hopefully let me know whether we can expect openal-soft to go into F10/F11. If not, I think we'll have to roll back this package to the last major version, which would... well, suck.
I can make an OpenAL-Soft package for F10/F11. But than must the alienarena recompiled with openal-soft because opeal-soft lib is libopenal.so.1 not libopenal.so.0.
(In reply to comment #8) > I can make an OpenAL-Soft package for F10/F11. > But than must the alienarena recompiled with openal-soft because opeal-soft lib > is libopenal.so.1 not libopenal.so.0. That is understood. Just let me know when the packages are built and pushed as updates so I can do the alienarena rebuilds.
First i must contact all packager that use openal then i can make the package.
(In reply to comment #10) > First i must contact all packager that use openal then i can make the package. Thomas, aren't the new openal-soft packages parallel installable to the old openal packages? In that case I see no reason to coordinate this with the packagers of other openal using packages. Once openal-soft hits F-11 / F-10, they can choose to rebuild their packages to make the switch or just leaves things as is, right ?
I think that: Obsoletes: openal <= 0.0.10 Provides: openal = %{version} Will replace openal?
(In reply to comment #12) > I think that: > Obsoletes: openal <= 0.0.10 > Provides: openal = %{version} > Will replace openal? Right, but the library has a different soname right? So there is no reason for the obsoletes, the 2 packages should be installable parallel without problems (atleast the main parts, the -devel parts is a different story).
OpenAL-Soft is an update package for OpenAL.
I know that openal-soft is intended to replace openal eventually, but given that it has a different soname and a different package name, the 2 can be installed in parallel and your mail to the devel list gave me the impression that was the whole idea (for now until all packages are switched). I got the impression from your mail that it would be good to move packages using openal over to openal-soft before F-12, but that that was not absolutely necessary as they would keep functioning with the old openal too (for now). This is also what I / we propose for F-11 and F-10 have a parallel installable openal-soft for alienarena (and maybe other packages who want to move) and keep the old openal around, so no obsoletes.
For what it's worth, I agree with Hans. Having it replace openal in F-12 and forward is correct, but we simply need it as an option in F-10/F-11.
i will build it but now i must wait for my f10/f11 cvs branch add on the cvs for it :)
Now you can find openal-soft in testing repro please rebuild it and push it into testing.
(In reply to comment #18) > Now you can find openal-soft in testing repro please rebuild it and push it > into testing. Yes and this one has the obsoletes for openal which it should not have! I know your English isn't the best, but please try to understand, were not going to blindly rebuild all openal using packages for F-11 and F-10. Instead the F-10 and F-11 openal-soft should NOT have the Obsoletes for regular openal (and a conflicts for openal-devel), like the initial versions for F-12 used to have. So please remove (unpush) the current openal-soft from F-10 / F-11 updates testing and do a new version without the Obosoletes / Provides for regular openal (and with a conflicts for openal-devel instead). Thank You! Regards, Hans
For F-10 and F-11 it is in submitting for Stable with conflicts but in rawhide with ob... I hope now is all okay :)
https://admin.fedoraproject.org/updates/openal-soft-1.8.466-7.fc11 https://admin.fedoraproject.org/updates/openal-soft-1.8.466-7.fc10
(In reply to comment #20) > For F-10 and F-11 it is in submitting for Stable with conflicts but in rawhide > with ob... > > I hope now is all okay :) All packages look good now, thanks!
Please request buildsystem tags for these updates so I can build against them.
What´s the status here? OpenAL-Soft is in F-10/F-11
(In reply to comment #23) > Please request buildsystem tags for these updates so I can build against them. Spot, Thomas pushed the updates directly to stable, so you should be able to build against openal-soft now, without needing any tagging.
alienarena-7.30-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/alienarena-7.30-2.fc10
alienarena-7.30-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/alienarena-7.30-2.fc11
Okay, I have created the updates for this. Please, if you have reported this issue, go and download this update and test it. If it resolves this issue for you, please give a karma vote on the update, so I will know I didn't break anything else. :)
Thanks - works for me, with the new openal-soft packages also pending in koji. Reported positive karma in koji.
alienarena-7.30-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
alienarena-7.30-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 531640 has been marked as a duplicate of this bug. ***
This bug was fixed. If it's reappeared in Rawhide, either this bug should be reopened, or bug #531640 shouldn't be marked as a duplicate.
This issue still exists in the latest F12 packages: > rpm -q alienarena openal-soft alienarena-7.32-1.fc12.x86_64 openal-soft-1.10.622-2.fc12.x86_64 > alienarena added /usr/share/alienarena/data1 to search paths added /usr/lib64/alienarena/data1 to search paths added ./data1 to search paths using /home/user/.codered/data1/ for writing added /home/user/.codered/data1 to search paths added /usr/share/alienarena/arena to search paths added /usr/lib64/alienarena/arena to search paths using /home/user/.codered/arena/ for writing added /home/user/.codered/arena to search paths execing default.cfg couldn't exec config.cfg Console initialized. ------- sound initialization ------- Segmentation fault (core dumped) alienarena[28202]: segfault at 2 ip 00000030b2c474b1 sp 00007fff6b1a5840 error 4 in libc-2.11.so[30b2c00000+16f000]
I don´t know but can you choose in the settings witch sound backed you prefer? Ala Alsa, OSS oder PulseAudio when yes please test it with Alsa and PulseAudio. @Maintainer please report the to the Upstream and let me know what they think about that please.
openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12
#544637 bug report with backtrace
https://bugzilla.redhat.com/show_bug.cgi?id=544637
That bug is not an openal-soft bug i have talked with an openal-soft dev and he find the problem in alienarena code and he will report that bug. When i have more infos i will post it here.
http://corent.proboards.com/index.cgi?board=bugreport&action=display&thread=4540
The bug will fixed in 7.33. I´m closing the bug.
(In reply to comment #41) > The bug will fixed in 7.33. I´m closing the bug. Actually we already have a fix for this in our packages, but with a small bug where we dlopenened openal.so.x.y instead of just openal.so.x, causing pretty much the same crash when openal got rebased to a newer upstream, changing the y in openal.so.x.y . We already have this small bug in our fix fixed in rawhide, and I'm now building an F-12 update with this fixed too. So expect updated packages fixing this soon. Note though, that even with this fixed, alienarena won't work for me, as it hangs on startup while initializing sound, this is with openal-soft-1.10.622-2.fc12, quake3 has the same issue. openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12 fixes these hangs for me, so should probably be pushed to updates stable soon, as it seems to be a better version to use then openal-soft-1.10.622-2.fc12 . Also the openal-soft-1.10.622-3.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc12 version seems to only have been build for fc12, meaning that we now have a broken upgrade path. I'll file a bug against openal-soft for this to make sure this gets build for development/rawhide too.
alienarena-7.32-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/alienarena-7.32-2.fc12
alienarena-7.32-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 544637 has been marked as a duplicate of this bug. ***
*** Bug 542289 has been marked as a duplicate of this bug. ***
*** Bug 542207 has been marked as a duplicate of this bug. ***
*** Bug 546972 has been marked as a duplicate of this bug. ***
*** Bug 539711 has been marked as a duplicate of this bug. ***
*** Bug 530921 has been marked as a duplicate of this bug. ***
*** Bug 530922 has been marked as a duplicate of this bug. ***
*** Bug 544934 has been marked as a duplicate of this bug. ***
Looks like this problem still happen in some systems. I have a segmentation fault with "sound initialization" $rpm -q alienarena openal-soft alienarena-7.32-1.fc11.i586 openal-soft-1.11.753-1.fc11.i586 I think that the alienarena-7.32-2 bugfix never appear in Fedora 11 updates.
Good catch! The update is building now, will be submitted shortly.
alienarena-7.32-2.fc11.1 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/alienarena-7.32-2.fc11.1
alienarena-7.32-2.fc11.1 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.