crashes on mipsel

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Execute opentyrian.
2. Crashes on start.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
0.0.0.0+r973-1~getdeb1 on Debian Squeeze on mipsel64 hardware.

Please provide any additional information below.
kip@kip-netbook:~/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973$ ls
COPYING  crosscompile.mk  debian  linux            macosx    NEWS  opentyrian  
src
CREDITS  Data             doc     lower-script.sh  Makefile  obj   README
kip@kip-netbook:~/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973$ cat /proc/cpuinfo 
system type     : lemote-yeeloong-2f-8.9inches
processor       : 0
cpu model       : ICT Loongson-2 V0.3  FPU V0.1
BogoMIPS        : 797.00
wait instruction    : no
microsecond timers  : yes
tlb_entries     : 64
extra interrupt vector  : no
hardware watchpoint : yes, count: 0, address/irw mask: []
ASEs implemented    :
shadow register sets    : 1
kscratch registers  : 0
core            : 0
VCED exceptions     : not available
VCEI exceptions     : not available

kip@kip-netbook:~/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973$ gdb --args 
./opentyrian --data=/home/kip/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973/Data/
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mipsel-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/home/kip/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973/opentyrian...done.
(gdb) r
Starting program: 
/home/kip/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973/opentyrian 
--data=/home/kip/Desktop/OpenTyrian/opentyrian-0.0.0.0+r973/Data/
[Thread debugging using libthread_db enabled]

Welcome to... >> OpenTyrian Classic (unknown revision) <<

Copyright (C) 2007-2009 The OpenTyrian Development Team

This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.  See the file GPL.txt for details.

warning: failed to open 'tyrian.cfg': No such file or directory

Invalid or missing TYRIAN.CFG! Continuing using defaults.

warning: failed to open 'opentyrian.conf': No such file or directory
warning: failed to open 'tyrian.sav': No such file or directory

Program received signal SIGILL, Illegal instruction.
0x004cccf4 in frameCountMax ()
(gdb) bt full
#0  0x004cccf4 in frameCountMax ()
No symbol table info available.
#1  0x2b15aa74 in ?? () from /usr/lib/libxcb.so.1
No symbol table info available.
warning: GDB can't find the start of the function at 0x2b15aa73.

    GDB is unable to find the start of the function at 0x2b15aa73
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2b15aa73 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

Original issue reported on code.google.com by kip.war...@gmail.com on 2 Jul 2012 at 9:58

[GoogleCodeExporter]

Could you run it in valgrind?

Original comment by mindless...@gmail.com on 3 Jul 2012 at 3:27

[GoogleCodeExporter]

I'd love to. Unfortunately valgrind isn't supported on that architecture. The 
autotools classifies it as mips64el. Is there something more I can give through 
GDB?

Original comment by kip.war...@gmail.com on 3 Jul 2012 at 3:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm afraid that aside from some intensive step debugging, without valgrind I 
wouldn't know how to determine why/where the stack is being clobbered.  Even 
what little is left in the backtrace is nothing to go on -- frameCountMax isn't 
even a function.

Original comment by mindless...@gmail.com on 3 Jul 2012 at 5:43

[GoogleCodeExporter]

Yes, I figured the stack trace didn't look particularly useful. The file was 
compiled with debugging symbols and unstripped. I wonder if there is anything 
more I can do to add more debugging information.

Original comment by kip.war...@gmail.com on 3 Jul 2012 at 5:48

[GoogleCodeExporter]

Just commited rc4e51e, see if it fixes it. The parameter parsing code for 
--data had a bug.

Original comment by yuriks...@gmail.com on 3 Jul 2012 at 11:25

• Changed state: Accepted

[GoogleCodeExporter]

Hey Yuriks. Thanks, but I just tried changeset 1001:c4e51eb465ae, but no love. 
Same console output before the same crash.

Original comment by kip.war...@gmail.com on 4 Jul 2012 at 12:21

[GoogleCodeExporter]

Turns out it wasn't an actual bug, just confusing code.

I think the only thing to be done then is to put some printf's to narrow down 
the site of the crash. By the console messages, it's somewhere between line 252 
(JE_loadConfiguration();) and line 262 (init_joysticks();) in opentyr.c.

Or if you want you can drop by on our IRC (#tyrian @ irc.freenode.net).

Original comment by yuriks...@gmail.com on 6 Jul 2012 at 1:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hey Yurks. I think I found where the segill is being raised, src/video.c:41 on 
the call to SDL_InitSubSystem(SDL_INIT_VIDEO). I know this machine has very 
poor graphics capabilities and has no 3d hardware accelerator. I tried stepping 
into the function with gdb but it doesn't look like I have debugging symbols 
installed for sdl1.2. Or maybe I do, but something needs to be passed to 
sdl-config in your makefile?

Original comment by kip.war...@gmail.com on 9 Jul 2012 at 12:36

[GoogleCodeExporter]

This looks to be an SDL bug.

Original comment by mindless...@gmail.com on 12 Oct 2012 at 12:49

• Changed state: WontFix

[GoogleCodeExporter]

Probably. Sorry for having wasted your time.

Original comment by kip.war...@gmail.com on 12 Oct 2012 at 12:54

[GoogleCodeExporter]

I'm getting the same issue on the X86_64 architecture, so I'm don't think this 
is an SDL bug, but a bug caused by some difference between 32-bit and 64-bit.

Original comment by draconis...@lycos.com on 27 Apr 2013 at 5:20

[GoogleCodeExporter]

I do development and testing on x86_64, so I don't think that's it.

Original comment by mindless...@gmail.com on 28 Apr 2013 at 9:25