Bug 1018398 - openarena crash: recursive error after: program tried to execute code outside VM
openarena crash: recursive error after: program tried to execute code outside VM
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: quake3 (Show other bugs)
22
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-11 17:20 EDT by Brendan Jones
Modified: 2015-03-09 20:54 EDT (History)
22 users (show)

See Also:
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 04:26:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
openarena crashlog (7.80 KB, text/plain)
2013-10-11 17:20 EDT, Brendan Jones
no flags Details
patch -- fix fastcall problem (8.13 KB, patch)
2014-07-19 08:57 EDT, Jeff Layton
no flags Details | Diff
quake3 - update package to more recent tarball (22.79 KB, patch)
2014-09-01 06:51 EDT, Jeff Layton
no flags Details | Diff
/home/andre/.openarena/baseoa/crashlog.txt (1.26 KB, text/plain)
2014-09-04 11:51 EDT, Andre Robatino
no flags Details

  None (edit)
Description Brendan Jones 2013-10-11 17:20:20 EDT
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.
Comment 1 Vít Ondruch 2013-10-24 03:45:30 EDT
The same on F20. The same workaround helped.
Comment 2 Mildred 2013-12-08 11:00:55 EST
Compiling ioquake3 from source (git repository) also helps.

https://bugzilla.icculus.org/show_bug.cgi?id=5702 might be interesting to look at
Comment 3 Mildred 2013-12-08 11:01:54 EST
Git commit 2ba7a337156586db6aa595cae066502e5e57de3e is working fine
Comment 4 Paul DeStefano 2014-05-26 20:09:28 EDT
I don't understand.  Why hasn't a fix been published for this, at least for F20?
Comment 5 Paul DeStefano 2014-06-04 05:22:43 EDT
I think it's a ligitmate question because you cannot downgrade to a working version of quake3 in F20.
Comment 6 Andre Robatino 2014-06-22 21:32:32 EDT
https://bugzilla.redhat.com/show_bug.cgi?id=1049693 (for F20) appears to be a duplicate of this.
Comment 7 Andre Robatino 2014-06-22 21:33:18 EDT
Sorry for removing the needinfo.
Comment 8 Markus S. 2014-07-13 10:47:36 EDT
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?
Comment 9 Jeff Layton 2014-07-19 08:57:05 EDT
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.
Comment 10 Andre Robatino 2014-08-29 14:05:51 EDT
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.
Comment 11 Jeff Layton 2014-08-31 11:30:01 EDT
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?
Comment 12 Xavier Lamien 2014-08-31 19:11:16 EDT
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.
Comment 13 Andre Robatino 2014-09-01 05:21:23 EDT
(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.
Comment 14 Jeff Layton 2014-09-01 06:51:29 EDT
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.
Comment 15 hannes 2014-09-01 12:30:37 EDT
Sorry to say, but ten months without response from the maintainer is what I call non-responsive.
Comment 16 Xavier Lamien 2014-09-01 22:09:39 EDT
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.
Comment 17 Xavier Lamien 2014-09-01 22:10:19 EDT
For the record, I did test it on x86_64 and arm boxes.
Comment 18 Jeff Layton 2014-09-02 06:46:32 EDT
(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.
Comment 19 Andre Robatino 2014-09-03 15:56:09 EDT
(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?
Comment 20 Xavier Lamien 2014-09-04 11:36:44 EDT
You mean F21 as the linked scratch build is F20 already.
Comment 21 Andre Robatino 2014-09-04 11:49:58 EDT
(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.
Comment 22 Andre Robatino 2014-09-04 11:51:04 EDT
Created attachment 934520 [details]
/home/andre/.openarena/baseoa/crashlog.txt
Comment 23 Jeff Layton 2014-09-04 11:53:20 EDT
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).
Comment 24 Xavier Lamien 2014-09-04 15:18:27 EDT
Yeah...I'll look into that hopefully, end of this week of next one.
I'll be traveling starting tomorrow for the record.
Comment 25 Dawid Gajownik 2014-09-08 11:44:56 EDT
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
Comment 26 Xavier Lamien 2014-09-21 02:46:04 EDT
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.
Comment 27 Jeff Layton 2014-09-21 08:20:37 EDT
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.
Comment 28 Joe Brockmeier 2014-11-08 15:21:24 EST
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?
Comment 29 Fred Wittekind IV 2014-12-30 14:27:45 EST
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.
Comment 30 Paul DeStefano 2015-01-13 00:11:42 EST
(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.
Comment 31 Fred Wittekind IV 2015-01-13 17:58:40 EST
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.
Comment 32 Paul DeStefano 2015-01-26 04:05:39 EST
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?
Comment 33 Brendan Jones 2015-01-26 04:33:00 EST
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.
Comment 34 Paul DeStefano 2015-01-26 05:30:44 EST
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.
Comment 35 Vít Ondruch 2015-01-26 05:42:32 EST
(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.
Comment 36 Gwyn Ciesla 2015-02-26 15:17:44 EST
This works for me, I'll take it from here.
Comment 37 Fedora Update System 2015-02-26 15:46:38 EST
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
Comment 38 Fedora Update System 2015-02-26 15:46:43 EST
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
Comment 39 Fedora Update System 2015-02-26 15:46:50 EST
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
Comment 40 Andre Robatino 2015-02-26 17:28:50 EST
Works for me on F21. Thanks!
Comment 41 Fedora Update System 2015-02-27 14:44:18 EST
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).
Comment 42 Jaroslav Reznik 2015-03-03 12:18:15 EST
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
Comment 43 Fedora Update System 2015-03-09 04:26:07 EDT
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.
Comment 44 Fedora Update System 2015-03-09 20:54:18 EDT
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.
Comment 45 Fedora Update System 2015-03-09 20:54:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.