Bug 183969 - Review Request: worminator - Sidescrolling platform and shoot'em up action-game
Review Request: worminator - Sidescrolling platform and shoot'em up action-game
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Wart
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-03-04 05:07 EST by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-06 03:41:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-03-04 05:07:37 EST
Spec Name or Url: http://home.zonnet.nl/jwrdegoede/worminator.spec
SRPM Name or Url: http://home.zonnet.nl/jwrdegoede/worminator-3.0R2.1-1.src.rpm
Description:
You play as The Worminator and fight your way through many levels of madness
and mayhem. Worminator features nine unique weapons, visible character damage,
full screen scrolling, sound and music, and much more!

Notice that you will also need the data files, I've created a seperate specfile for this:
http://home.zonnet.nl/jwrdegoede/worminator-data.spec
Sorry no SRPM, the data is too large (only 6MB) for my sucky ISP.
Comment 1 Wart 2006-03-04 20:10:48 EST
MUST
====
* rpmlint output clean (worminator only)
* Package named correctly
* GPL license OK.  Thanks for including the license change discussion in %doc
* spec file legible, in Am. English
* Source matches upstream (srpm for -data not provided)
* Successfully compiles and builds on at least one platform (FC-4 x86_64)
* no locale data, shared libraries, or static libraries
* No excessive Requires: or BR:
* Summary and description ok
* macro use consistent
* Game content permissible
* -data package owns the directory that it creates.
* Not relocatable
* %doc does not affect runtime
* 

GAMES SIG MUST
=============
* application and data packaged separately
* Data in %{datadir}/games permitted (see below)
* spec file group ok
* license file and change discussion included
* file ownership ok

SHOULD
======
* Builds cleanly in mock for FC-4 i386, FC-4 x86_64, and FC-5 i386

MUSTFIX
=======
* Data should be a noarch package.  Use:
BuildArch: noarch
This will also clean up the rpmlint error on the -data package.

* desktop file category incorrect. It should be:
Category: Application;Game;ArcadeGame;

* Segfaults on FC4-x86_64.  strace shows that the game hangs after the segfault,
leaving a lingering worminator process.

* Started up on FC5-i386, but locked up during the tutorial.

SHOULDFIX
=========
* Data files should be put in /usr/share/worminator, not
/usr/share/games/worminator.  I realize there is still a discussion on the
Games SIG regarding this, so I won't consider it a blocker.
Comment 2 Hans de Goede 2006-03-04 20:43:38 EST
MUSTFIX
=======
* Data should be a noarch package.  Use:
BuildArch: noarch
This will also clean up the rpmlint error on the -data package.

* desktop file category incorrect. It should be:
Category: Application;Game;ArcadeGame;

I'll fix these 2 soon (no time tight now)


* Segfaults on FC4-x86_64.  strace shows that the game hangs after the segfault,
leaving a lingering worminator process.
Hmm, this could be because of the old (ancient) allegro in FC-4, unfortunatly it
can't be upgraded because of .soname changes. Or did you happen to start it
through ssh , there is are known allegro problems when doing this.

* Started up on FC5-i386, but locked up during the tutorial.
Hmm, it works fine here (x86_64), where exactly did it lock up, did you switch
to a console and then attach gdb? Can you reproduce this?
Comment 3 Wart 2006-03-04 21:44:35 EST
(In reply to comment #2)

> * Segfaults on FC4-x86_64.  strace shows that the game hangs after the segfault,
> leaving a lingering worminator process.
> Hmm, this could be because of the old (ancient) allegro in FC-4, unfortunatly it
> can't be upgraded because of .soname changes. Or did you happen to start it
> through ssh , there is are known allegro problems when doing this.

I was running it directly on the desktop, not via ssh.

> * Started up on FC5-i386, but locked up during the tutorial.
> Hmm, it works fine here (x86_64), where exactly did it lock up, did you switch
> to a console and then attach gdb? Can you reproduce this?

This is definitely reproducible, but it happens at slightly different places
during the tutorial.  It's always at or shortly after the 'Press Z to duck'
screen.  gdb shows that it's hung in reset_sound(), and in fact, there is no
sound playing for me.  I'm running this inside of vmware, and it's possible that
vmware is competing with the host system's sound resources.  I'll try to bring
up FC-5 directly and see if it still happens.
Comment 4 Wart 2006-03-04 21:53:49 EST
(In reply to comment #3)
> (In reply to comment #2)

> > * Started up on FC5-i386, but locked up during the tutorial.
> > Hmm, it works fine here (x86_64), where exactly did it lock up, did you switch
> > to a console and then attach gdb? Can you reproduce this?
> 
> This is definitely reproducible, but it happens at slightly different places
> during the tutorial.  It's always at or shortly after the 'Press Z to duck'
> screen.  gdb shows that it's hung in reset_sound(), and in fact, there is no
> sound playing for me.

Here's the stack while it's hung:

#0  0x00501410 in ?? ()
#1  0xbfc7cc88 in ?? ()
#2  0x000001f4 in ?? ()
#3  0x00000001 in ?? ()
#4  0x00276bec in poll () from /lib/libc.so.6
#5  0x04e1f060 in snd_pcm_direct_check_interleave () from /lib/libasound.so.2
#6  0x04e1f4cf in snd_pcm_direct_server_create () from /lib/libasound.so.2
#7  0x04e17b12 in snd_pcm_dmix_open () from /lib/libasound.so.2
#8  0x04e184c9 in _snd_pcm_dmix_open () from /lib/libasound.so.2
#9  0x04de6b35 in snd_pcm_free () from /lib/libasound.so.2
#10 0x04de71b6 in snd_pcm_free () from /lib/libasound.so.2
#11 0x04de725b in snd_pcm_open_slave () from /lib/libasound.so.2
#12 0x04e01c3c in _snd_pcm_plug_open () from /lib/libasound.so.2
#13 0x04de6b35 in snd_pcm_free () from /lib/libasound.so.2
#14 0x04de7283 in snd_pcm_open_slave () from /lib/libasound.so.2
#15 0x04e1f674 in _snd_pcm_asym_open () from /lib/libasound.so.2
#16 0x04de6b35 in snd_pcm_free () from /lib/libasound.so.2
#17 0x04de71b6 in snd_pcm_free () from /lib/libasound.so.2
#18 0x00b2e34d in ?? () from /usr/lib/allegro//4.2/alleg-alsadigi.so
#19 0x005c163e in install_sound () from /usr/lib/liballeg.so.4.2
#20 0x080883ac in reset_sound () at Worminator.c:3136
#21 0x0808b66a in initialize () at Worminator.c:3258
#22 0x080ab25b in main () at Worminator.c:309
Comment 5 Hans de Goede 2006-03-05 02:52:31 EST
MUSTFIX
=======
* Data should be a noarch package.  Use:
BuildArch: noarch
This will also clean up the rpmlint error on the -data package.

Fixed, new spec file at:
http://home.zonnet.nl/jwrdegoede/worminator-data.spec

* desktop file category incorrect. It should be:
Category: Application;Game;ArcadeGame;

Fixed, new srpm at the same url as the previous one (I didn't bump release): 
http://home.zonnet.nl/jwrdegoede/worminator-3.0R2.1-1.src.rpm

* Segfaults on FC4-x86_64.  strace shows that the game hangs after the segfault,
leaving a lingering worminator process.

Hmm, I really believe this is because of the old (ancient) allegro in FC-4, 
concedering that FC-5 is almost released and since I don't have any FC-4
installs I won't fix this.

* Started up on FC5-i386, but locked up during the tutorial.
Looking at your strace this seems buried deep in alsalib, thus not a worminator
problem, most likely a problem with alsa and vmware, also is your rawhide fully
up2date? I've tried to reproduce this as you described, but it works for me.

I've extensivly tested this on FC-5 x86_64 and Fc-5 i386 and I've seen no
(unfixed) hangs or crashes. I've also had this tested on PPC to make sure me
endian dixes where correct and there it worked too. Also the Cru packager has
been playing it without any problems.

I have to ask you to believe me here that worminator is not an unstable pile of
XXXX, but that you just have 2 unlucky configurations.
Comment 6 Wart 2006-03-05 19:13:05 EST
(In reply to comment #5)

> * Segfaults on FC4-x86_64.  strace shows that the game hangs after the segfault,
> leaving a lingering worminator process.
> 
> Hmm, I really believe this is because of the old (ancient) allegro in FC-4, 
> concedering that FC-5 is almost released and since I don't have any FC-4
> installs I won't fix this.
> 
> * Started up on FC5-i386, but locked up during the tutorial.
> Looking at your strace this seems buried deep in alsalib, thus not a worminator
> problem, most likely a problem with alsa and vmware, also is your rawhide fully
> up2date? I've tried to reproduce this as you described, but it works for me.
> 
> I've extensivly tested this on FC-5 x86_64 and Fc-5 i386 and I've seen no
> (unfixed) hangs or crashes. I've also had this tested on PPC to make sure me
> endian dixes where correct and there it worked too. Also the Cru packager has
> been playing it without any problems.
> 
> I have to ask you to believe me here that worminator is not an unstable pile of
> XXXX, but that you just have 2 unlucky configurations.

I finally got a FC5-x86_64 install on my desktop (this time not running in
vmware), and it ran without problems.  Since the earlier issues have been
addressed, and I verified that it runs correctly:

APPROVED
Comment 7 Hans de Goede 2006-03-06 02:15:09 EST
Imported, added to owners.list and build requested will close as soon as the
build(s) complete.
Comment 8 Hans de Goede 2006-03-06 03:41:40 EST
Build successfully, closing.
Comment 9 Hans de Goede 2006-03-08 17:08:41 EST
I just found out on the allegro-devel mailing list why worminator was crashing
for you with FC-4 - i386. You were running FC-4 i386 on an x86_64 and thus had
NX protection on, and allegro contains a bug that causes it to fail on i386 with
NX (not on x86_64 itself because there it doesn't generate asm as it does on i386).

I've this fixed in FE-devel CVS.
Comment 10 Wart 2006-03-08 19:05:39 EST
(In reply to comment #9)
> I just found out on the allegro-devel mailing list why worminator was crashing
> for you with FC-4 - i386. You were running FC-4 i386 on an x86_64 and thus had
> NX protection on, and allegro contains a bug that causes it to fail on i386 with
> NX (not on x86_64 itself because there it doesn't generate asm as it does on
i386).

Not quite.  This was on native FC-4 x86_64.

$ rpm -qa allegro*
allegro-devel-4.0.3-13.x86_64
allegro-4.0.3-13.x86_64

Here's the stack trace (sorry, there was no useful allegro-debuginfo package):

(gdb) run
Starting program: /usr/bin/worminator
[Thread debugging using libthread_db enabled]
[New Thread 46912496357536 (LWP 5533)]
[New Thread 1084229984 (LWP 5557)]
[New Thread 1094719840 (LWP 5558)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496357536 (LWP 5533)]
0x0000003ade56a413 in _int_free () from /lib64/libc.so.6
(gdb) thread apply all bt

Thread 3 (Thread 1094719840 (LWP 5558)):
#0  0x0000003ade5c2682 in __select_nocancel () from /lib64/libc.so.6
#1  0x0000003d04b79bc8 in seqbuf_dump () from /usr/lib64/liballeg.so.4.0
#2  0x0000003adf00697c in start_thread () from /lib64/libpthread.so.0
#3  0x0000003ade5c992e in clone () from /lib64/libc.so.6
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 1084229984 (LWP 5557)):
#0  0x0000003ade5c2682 in __select_nocancel () from /lib64/libc.so.6
#1  0x0000003d04b7a5f0 in _read_os_type () from /usr/lib64/liballeg.so.4.0
#2  0x0000003adf00697c in start_thread () from /lib64/libpthread.so.0
#3  0x0000003ade5c992e in clone () from /lib64/libc.so.6
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 46912496357536 (LWP 5533)):
#0  0x0000003ade56a413 in _int_free () from /lib64/libc.so.6
#1  0x0000003ade56ac4e in free () from /lib64/libc.so.6
#2  0x0000003d04b78cd2 in _unix_unload_modules ()
   from /usr/lib64/liballeg.so.4.0
#3  0x0000003d04b6c862 in install_sound () from /usr/lib64/liballeg.so.4.0
#4  0x0000000000412b28 in reset_sound () at Worminator.c:3136
#5  0x0000000000412e67 in initialize () at Worminator.c:3258
#6  0x0000000000459abf in _mangled_main (argc=Variable "argc" is not available.
) at Worminator.c:309
#7  0x0000003ade51c3cf in __libc_start_main () from /lib64/libc.so.6
#8  0x0000000000407ef9 in _start ()
#9  0x00007fffffe2d348 in ?? ()
#10 0x0000000000000000 in ?? ()

Of course, this is all academic unless you plan to build worminator on FC-4.
Comment 11 Hans de Goede 2006-03-09 01:01:08 EST
Darn, well the NX stuff still is a real problem. And as said this is all
acadamic because I don't plan to release worminator for FC-4 because of the old
allegro there.

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