Bug 1018398
| Summary: | openarena crash: recursive error after: program tried to execute code outside VM | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brendan Jones <brendan.jones.it> | ||||||||||
| Component: | quake3 | Assignee: | Gwyn Ciesla <gwync> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 22 | CC: | aron, eliadevito, fri8k, gajownik, gilwooden, gwync, igor.redhat, jlayton, johannes.lips, jzb, kamikazow, kazimieras.vaina, lxtnow, marcandre.lureau, mildred-bug.redhat, nickysn, parrenin, prd-fedora, redhat-bugzilla, robatino, rom, vondruch | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | quake3-1.36-21.svn2102.fc21 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2015-03-09 08:26:07 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
The same on F20. The same workaround helped. Compiling ioquake3 from source (git repository) also helps. https://bugzilla.icculus.org/show_bug.cgi?id=5702 might be interesting to look at Git commit 2ba7a337156586db6aa595cae066502e5e57de3e is working fine I don't understand. Why hasn't a fix been published for this, at least for F20? I think it's a ligitmate question because you cannot downgrade to a working version of quake3 in F20. https://bugzilla.redhat.com/show_bug.cgi?id=1049693 (for F20) appears to be a duplicate of this. Sorry for removing the needinfo. I can confirm this. I can also confirm that the regular release does not have this problem. Is there a reason why Fedora ships SVN checkouts instead of release versions? Created attachment 919275 [details]
patch -- fix fastcall problem
Here's a fedora dist-git patch which adds the upstream patch for this problem to the package. It seems to fix the immediate bug, but it does seem like it might be nice to eventually update the tarball to something much newer.
Is the maintainer still there? Otherwise it looks like it'll be necessary to go through https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers , otherwise this will be broken in F21 Final. It would be nice to get a response soon enough to get this fixed in F20 as well before that goes EOL. Xavier, do you have any interest in maintaining the quake3 and related packages anymore? Either way, can you respond to this bug since they are completely broken now? I can't see Andre, why would you go through a "non-responsive-maintainers" without getting in touch with me by any other possible way. That's not how this policy works. Thanks Jeff for poking at me with the needinfo which, is one of the best way to get in touch with ticket's assignee. I will look at this patch and check upstream release to align this package. (In reply to Xavier Lamien from comment #12) > I can't see Andre, why would you go through a "non-responsive-maintainers" > without getting in touch with me by any other possible way. That's not how > this policy works. I WAS trying to get in touch by another method, which is why I posted comment 10. I didn't realize it was necessary to set the needinfo to get a reply to my query (the wiki page makes no mention of using needinfo, only of "a maintainer isn't answering their bugs", and I already have at least one bugzilla query for another Component with needinfo that has been ignored anyway). If it is expected to use needinfo, the wiki page should be edited accordingly. Anyway, thanks for replying. Created attachment 933301 [details]
quake3 - update package to more recent tarball
Here's a start on a package update for quake3. I just used git archive on the ioq3 git tree to generate a new tarball. I had started working on it a while back, but it doesn't work yet and I don't really have the time to finish it up. Feel free to take this and run with it if you like.
The big stumbling block is that they've broken out some of the renderers into .so libs, and we need a scheme that allows those to be dlopened properly.
Sorry to say, but ten months without response from the maintainer is what I call non-responsive. here's a scratch build. if you guys can test it in the mean time. http://koji.fedoraproject.org/koji/taskinfo?taskID=7505803 Ho, didn't see Jeff, you did one, will merge you work with mine before push anything. For the record, I did test it on x86_64 and arm boxes. (In reply to Xavier Lamien from comment #16) > here's a scratch build. if you guys can test it in the mean time. > http://koji.fedoraproject.org/koji/taskinfo?taskID=7505803 > > Ho, didn't see Jeff, you did one, will merge you work with mine before push > anything. The quake3 package there will probably work fine, but the other ones like wop will fail. AFAICT, ioq3 will try to dlopen the render* libs in the fs_basepath, and that's different for the different game variants. I think the cleanest fix would be to add a new path for the dlopen search that doesn't change when the "game" changes, but I haven't sat down to do that work. (In reply to Xavier Lamien from comment #16) > here's a scratch build. if you guys can test it in the mean time. > http://koji.fedoraproject.org/koji/taskinfo?taskID=7505803 I'd test it, but unfortunately I only have Rawhide (and F21) running in VMs, and they don't support 3D acceleration, so openarena won't run. If no one else can test it, is it possible to do a scratch build for F20? You mean F21 as the linked scratch build is F20 already. (In reply to Xavier Lamien from comment #20) > You mean F21 as the linked scratch build is F20 already. Apologies, I didn't notice that the build target was F20. Just tested it, but doesn't work - I get an Error window that says Failed to load renderer. See "/home/andre/.openarena/baseoa/crashlog.txt" for details. Will attach file. Created attachment 934520 [details]
/home/andre/.openarena/baseoa/crashlog.txt
I tried out the worldofpadman package, and got this error: "Failed loading /usr/share/wop/renderer_opengl1_x86_64.so: /usr/share/wop/renderer_opengl1_x86_64.so: cannot open shared object file: No such file or directory" Failed to load renderer ...as I said in comment #18, the problem is that ioq3 really needs to be able to search for libraries to dlopen in a directory that is invariant with the fs_basepath. The ideal thing, I think would be to add a new cvar or something (fs_libpath maybe?), but that'll take a source level patch. I imagine that the ioq3 folks would be amenable to such a change though (though maybe there's some way to do that with the existing codebase without needing to patch it). Yeah...I'll look into that hopefully, end of this week of next one. I'll be traveling starting tomorrow for the record. It looks that there are broken symlinks (missing slash) in the package from scratch build: ls -l /usr/share/quake3/ | grep render lrwxrwxrwx. 1 root root 43 09-08 17:09 renderer_opengl1_x86_64.so -> /usr/lib64quake3/renderer_opengl1_x86_64.so lrwxrwxrwx. 1 root root 43 09-08 17:09 renderer_opengl2_x86_64.so -> /usr/lib64quake3/renderer_opengl2_x86_64.so [gajownik@ulquiorra ~]$ As a workaround I did this: cd /usr/share/quake3/ rm renderer_opengl1_x86_64.so ln -s /usr/lib64/quake3/renderer_opengl1_x86_64.so renderer_opengl1_x86_64.so rm renderer_opengl2_x86_64.so ln -s /usr/lib64/quake3/renderer_opengl2_x86_64.so renderer_opengl2_x86_64.so Hm...I'll double check that one. However, are other mod (i.e urbanterror) work? Jeff, did you have time to look closer to the issue you mentioned. I need to know if a I can push this pkg commit as a workaround in the mean time Jeff or I found the best way to patch the code. No, I haven't had time to look yet. It's probably not too hard to fix, but I haven't had the time to look. I'd imagine you'd need to add a new cvar for the lib location and then fix the dlopen wrappers to dtrt with it. Still seeing this issue as of Fedora 21 beta. It's been broken quite some time - any chance of getting the package updated/fixed before final release? https://bugzilla.redhat.com/show_bug.cgi?id=1169318 is a possible duplicate of this. For what it's worth, I tested the patch in attachment 919275 [details] with a build on a CentOS 7 machine, and corrected the crash for me. (In reply to Joe Brockmeier from comment #28) > Still seeing this issue as of Fedora 21 beta. It's been broken quite some > time - any chance of getting the package updated/fixed before final release? Rats. I was really hoping the answer to this would be 'yes'. I just upgraded and found that it's still broken. The patch in the attachment is dated Aug 2012, right? Fred, Was compiling quake3 difficult? Just curious if it was trivial or a pain. I assume it was easy, but since you did it, I figured I'd ask. The compile process was quite easy. I downloaded the newest Fedora SRPM, and applied the patch, and did a rpmbuild. Hardest bit was merging the patch with the newest SRPM. If your familiar with building packages from SRPM files, then this is no different. I do not know that status the symlink issue mentioned, but, the crash issue was definitely resolved (at least for me). I would be happy to share the RPM/SRPM files I have if you like, given, it's built for EL7, not Fedora, but, easy enough to rebuild from SRPM for Fedora, then at least you wouldn't have to try to merge in the patch yourself. Email me. Fred, Damn, failed to build. I tried just like you suggested. And, I think the patch applied okay, too; the build didn't choke on any of the patched files. So disappointed. Could you post your SRPM pkg somewhere? All, Has anyone tried a binary RPM from koji or rpmfind of v1.36.17 on F21? 1.36.17.svn2102.fc19 is what I'm using. When I have some spare cycles I will probably request maintainership and end this once and for all. Thanks Brendan, I figured it out, btw. Best I can tell, Catalyst installed libGL replacement caused /lib64/libGL.so.1.2.0 to be deleted. This caused the RPM build failure. I cheated and made a link myself and got it to compile. If there is a standard way to do this better, I'd like to know. One think didn't know was how to change the spec file so that the resulting RPM would supersede/replace the current quake3 package. In any case, that wasn't too hard to workaround, but wish I knew the right way, but off topic. Anyway, that's three confirmed patched cases. (In reply to Paul DeStefano from comment #34) > I figured it out, btw. Best I can tell, Catalyst installed libGL > replacement caused /lib64/libGL.so.1.2.0 to be deleted. This caused the RPM > build failure. I cheated and made a link myself and got it to compile. If > there is a standard way to do this better, I'd like to know. You might want to consider to use Mock for your builds: https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds This way you'll always build in vanilla environment. > One think didn't know was how to change the spec file so that the resulting > RPM would supersede/replace the current quake3 package. In any case, that > wasn't too hard to workaround, but wish I knew the right way, but off topic. You have to bump revision in .spec file. This works for me, I'll take it from here. quake3-1.36-21.svn2102.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/quake3-1.36-21.svn2102.fc20 quake3-1.36-21.svn2102.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/quake3-1.36-21.svn2102.fc21 quake3-1.36-22.svn2102.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/quake3-1.36-22.svn2102.fc22 Works for me on F21. Thanks! Package quake3-1.36-22.svn2102.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing quake3-1.36-22.svn2102.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-2794/quake3-1.36-22.svn2102.fc22 then log in and leave karma (feedback). This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 quake3-1.36-22.svn2102.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. quake3-1.36-21.svn2102.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. quake3-1.36-21.svn2102.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 811395 [details] openarena crashlog Openarena crashes on startup with the following: Loading vm file vm/ui.qvm... File "vm/ui.qvm" found in "/usr/share/openarena/baseoa/pak6-patch088.pk3" ...which has vmMagic VM_MAGIC_VER2 Loading 1555 jump table targets VM file ui compiled to 784949 bytes of code ui loaded in 1848448 bytes on the hunk ******************** ERROR: program tried to execute code outside VM ******************** recursive error after: program tried to execute code outside VM Downgrading quake3.x86_64 0:1.36-18.svn2102.fc20 to quake3.x86_64 0:1.36-17.svn2102.fc19 fixes the issue.