OpenTTD

Tasklist

FS#2703 - Throwing exception crashes OpenTTD

Attached to Project: OpenTTD
Opened by wossname (wossname) - Thursday, 05 March 2009, 20:41 GMT
Last edited by Remko Bijker (Rubidium) - Tuesday, 21 July 2009, 23:10 GMT
Type Bug
Category Core
Status Closed
Assigned To Thijs Marinussen (Yexo)
Operating System All
Severity Low
Priority Normal
Reported Version 0.7.0-beta1
Due in Version 0.7.2
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

After following the "Your First AI" (http://wiki.openttd.org/wiki/index.php/AI:Introduction#Your_First_AI) tutorial, running the AI results in the entire application terminating with the following message:

--------
terminate called after throwing an instance of 'AI_VMSuspend'
Aborted
--------

If the offending this.Sleep(50) line is removed then the AI runs correctly and as expected.
This task depends upon

Closed by  Remko Bijker (Rubidium)
Tuesday, 21 July 2009, 23:10 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Bug in GCC causing exceptions to crash if frame pointers are omitted.
Comment by Remko Bijker (Rubidium) - Thursday, 05 March 2009, 20:54 GMT
What version are you using exactly? 0.6.3 doesn't support NoAI AIs
Comment by Remko Bijker (Rubidium) - Thursday, 05 March 2009, 20:58 GMT
Also copying EXACTLY what is written in the wiki doesn't crash it for me. Could you attach your main.nut?
Comment by wossname (wossname) - Friday, 06 March 2009, 18:24 GMT
Sorry, I thought I'd set the version combobox properly. It's "0.7.0-beta1".

I've attached the offending main.nut file.

further info...

I was invoking my ai code by using...

start_ai anw_ai

...on the in-game console, the game was not paused at the time.

I compiled Openttd from the source bz2, (./configure ; make). No errors encountered. The game plays smoothly if I'm not messing with the AI.

I'm running the following:
* Fedora Core 4 (yeah I know it's ancient :))
* kernel: "kernel-2.6.17-1.2142_FC4"
* ...on an Intel Celery 1.5ghz single core

I'm really interested in writing AI for Openttd so I'd be up for a bit of debugging if you need me to.

Thanks,

Adam.
   main.nut (0.2 KiB)
Comment by wossname (wossname) - Friday, 06 March 2009, 18:25 GMT
Here's my info.nut for good measure...
   info.nut (0.5 KiB)
Comment by Remko Bijker (Rubidium) - Friday, 06 March 2009, 18:40 GMT
That AI reliably causes that crash for you? It doesn't do anything wrong for me.

Could you tell what compiler you're using exactly?
Comment by wossname (wossname) - Friday, 06 March 2009, 19:02 GMT
Yeah it happens every time. Actually I've got an Acer Aspire netbook I could try it on. I've got openttd 0.6.3 on that at the moment but I'll try reproducing this 'bug' on that machine tomorrow.

Anyway, here's the output from my compiler's version info...

$ g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)


My SDL version is thus:
SDL-1.2.8-4




I'll report back when I try this on my netbook.
Comment by wossname (wossname) - Saturday, 07 March 2009, 12:34 GMT
Well I guess it's my Fedora Core 4 box that is broken because my netbook does not suffer from this problem. As far as I'm concerned I'm happy enough to just use my netbook instead.



My netbook's compiler is as follows...

# g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)

SDL version:
SDL-1.2.13-1


Something else I noticed on my FC4 box is that after I've added my "anw_ai =" line to the openttd.cfg file, I start the game but there is no entry for "anw_ai" in the "AI Settings" dialog box. Could that be part of this problem, is the game not loading the AI properly on my FC4 box?

Anyway, I guess my first installation was broken in some way, my netbook is fine so I'm happy.
Comment by Remko Bijker (Rubidium) - Saturday, 07 March 2009, 23:08 GMT
I've installed FC4 (in VirtualBox) and it crashes in some library even before a game was started. Furthermore it (or Fedora) have messed up upgrading packages so I can't update gcc and friends to the exact version you're having.

This makes it kind of impossible for me to find the bug (and thus fix it). However it looks like it could be a compiler error. Does the binary from your netbook work on the FC4 machine?

Edit: got it a bit working with hacks, but it doesn't crash for me. I've got a different compiler and such, but this is as close as I can get to your installation and it's still unreproducable.
Comment by wossname (wossname) - Sunday, 08 March 2009, 11:28 GMT
FC4 can be somewhat of a stubborn mule.
The netbook's binary doesn't run on my FC4 box, this is likely to be a library conflict. Also the CPUtype is different so it probably wouldn't be a fair test anyway.

I guess we can chalk it up to a broken OS on a broken box.
Comment by Thunor (thunor) - Tuesday, 07 July 2009, 20:59 GMT
  • Field changed: Percent Complete (100% → 0%)
I am experiencing this bug on Zenwalk Linux 3.0, with gcc 3.4.6 and SDL 1.2.11. I cannot play a game with AI as it crashes mostly on 1st January 1952. This bug should not be simply ignored; it is not specific to Fedora Core 4.
Comment by Thijs Marinussen (Yexo) - Tuesday, 07 July 2009, 21:01 GMT
http://www.tt-forums.net/viewtopic.php?f=65&t=44208 contains an AI that reproduces the problem.
Comment by wossname (wossname) - Wednesday, 08 July 2009, 21:14 GMT
I'm interested to see that other people are having this trouble too.

I've still got my old FC4 box in the state I left it when I last posted here.

Let me know if you need my help, I'd be happy to do a bit of digging. I'm no longer looking to write AI, but if it helps others, then that's good enough for me.

Cheers.

Wosser.
Comment by Thijs Marinussen (Yexo) - Tuesday, 14 July 2009, 21:17 GMT
Can you try to run OpenTTD in gdb and post the stack trace of the crash? I was able to reproduce it at first, but for some reason I can't reproduce it anymore.
Comment by Thunor (thunor) - Sunday, 19 July 2009, 13:14 GMT
Running openttd 0.7.1 revision 16755 from SVN. The game crashes on 1st Jan 1952.

woden[games]$ gdb ./openttd
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /home/woden/Games/openttd-0.7.1-rev16755/games/openttd
[Thread debugging using libthread_db enabled]
[New Thread -1213650048 (LWP 3195)]
[New Thread -1213654096 (LWP 3198)]
[New Thread -1231328336 (LWP 3199)]
[Thread -1231328336 (zombie) exited]
dbg: [misc] Nested widgets give different results
[New Thread -1231328336 (LWP 3200)]
terminate called after throwing an instance of 'AI_VMSuspend'

Program received signal SIGABRT, Aborted.
[Switching to Thread -1213650048 (LWP 3195)]
0xb7c04847 in raise () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7c04847 in raise () from /lib/tls/libc.so.6
#1 0xb7c060d9 in abort () from /lib/tls/libc.so.6
#2 0xb7f40c6b in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#3 0xb7f3e8a4 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#4 0xb7f3e8e1 in std::terminate () from /usr/lib/libstdc++.so.6
#5 0xb7f3eac8 in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#6 0x080862ee in SQVM::Execute ()
#7 0x080871d7 in SQVM::Call ()
#8 0x085cd7b8 in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y
woden[games]$


Comment by Thijs Marinussen (Yexo) - Sunday, 19 July 2009, 14:19 GMT
I hope it's not too much to ask, but this stacktrace is pretty vague since it's from a release build. Could you create a debug build (configure with --enable-debug=3) and then get a stacktrace?
Comment by Thunor (thunor) - Sunday, 19 July 2009, 18:29 GMT
I have good news :) Until today the latest version would always crash with AI players, most of the time on 1st Jan 1952. But now I have successfully played 3 games with no crashes since I used "./configure --enable-debug=3"

There was one other thing that was different since my last compile: I didn't install the gm files into the gm folder, so to check that this wasn't causing problems I installed the gm files and I could still play AI games without crashes.

Therefore, configuring with --enable-debug=3 is the only different thing, which has fixed the problem for me!

Maybe this means something to you Thijs? I think it would be a good idea to get Wossy to try "./configure --enable-debug=3" too.

Regards,
Thunor
Comment by Remko Bijker (Rubidium) - Sunday, 19 July 2009, 18:32 GMT
Debug level 3 working and releases not is actually not very good news. Can you test whether debug level 1 and 2 work, or whether they are 'broken' in the same way as release builds?
Comment by Thunor (thunor) - Sunday, 19 July 2009, 20:02 GMT
Debug levels 1 and 2 also work for me. I have 3 existing save games from debug level 3, saved on 20th Dec 1951, 12 days before the first AI player is created which would normally crash the game, and I loaded these and they didn't crash. I also created and played through a new game for each recompile of debug levels 1 and 2 and they also didn't crash.

So, all 3 debug levels make the game playable for me.
Comment by Remko Bijker (Rubidium) - Monday, 20 July 2009, 00:00 GMT
  • Field changed: Severity (High → Low)
I've installed a Zenwork Linux 3.0 in VirtualBox (they don't like eachother very much).

It results in reproducing the issue, but without any useful solutions. Given that removing the "-fomit-frame-pointer" flag from the compiler fixes the issue makes me believe that it is a (rare) compiler issue. Apparantly it omits these frame pointers also when it shouldn't omit them; they aren't omitted with most other instances of the GCC compiler.

So there is at least a (fairly) feasible work around, although I am not happy applying that work around because it negatively influences the speed of release builds of OpenTTD.
Comment by Thunor (thunor) - Monday, 20 July 2009, 12:38 GMT
The good thing is that anyone in the future who experiences this problem will find a fix for it in this thread.

So far two people (Wossy and I) have made the effort to report it when using older Linux distributions, Wossy with gcc 4.1.2 on Fedora Core 4 and me with gcc 3.4.6 on Zenwalk 3.0, so it is by no means a commonly experienced problem.

To remove "-fomit-frame-pointer" from CFLAGS, I first ran ./configure and then edited objs/release/Makefile near the top (line 8) before I executed make. Possibly there's a way to do this via configure options but I don't know. Anyway, the game works with AI players and it's faster than using --enable-debug= :)

Cheers.
Comment by Remko Bijker (Rubidium) - Tuesday, 21 July 2009, 20:51 GMT
The easiest way I see is:
./configure CFLAGS=-fno-omit-frame-pointer

Loading...