I started a new thread because it must be a different problem, the version from jamespetts' git as of 8may worked for me. I tried both the downloaded 8.0 file as well as a self-compile from a fresh git pull. The 32bit downloaded file works fine (well, it starts, haven't gotten any further yet lol).
Here's the backtraces:
gdb simexp-jamespetts-2010-05-29
Program received signal SIGSEGV, Segmentation fault.
0x000000000061ede3 in display_fb_internal (xp=<value optimized out>, yp=<value optimized out>, w=<value optimized out>, h=12,
color=<value optimized out>, dirty=<value optimized out>, cL=182, cR=520, cT=267, cB=307) at simgraph16.cc:3095
3095 *lp++ = longcolval;
(gdb) bt
#0 0x000000000061ede3 in display_fb_internal (xp=<value optimized out>, yp=<value optimized out>, w=<value optimized out>, h=12,
color=<value optimized out>, dirty=<value optimized out>, cL=182, cR=520, cT=267, cB=307) at simgraph16.cc:3095
#1 0x0000000000621f34 in display_fillbox_wh_clip (xp=<value optimized out>, yp=<value optimized out>, w=<value optimized out>,
h=<value optimized out>, color=<value optimized out>, dirty=<value optimized out>) at simgraph16.cc:3129
#2 0x000000000049179e in button_t::zeichnen (this=0xa81bb8, offset=<value optimized out>) at gui/components/gui_button.cc:368
#3 0x00000000004a4724 in gui_table_t::paint_cells (this=0xa81698, offset=<value optimized out>) at gui/components/gui_table.cc:166
#4 0x00000000004a4a59 in gui_table_t::zeichnen (this=0xa81698, offset=...) at gui/components/gui_table.cc:349
#5 0x00000000004a352d in gui_scrollpane_t::zeichnen (this=0xa81898, pos=<value optimized out>)
at gui/components/gui_scrollpane.cc:148
#6 0x00000000004d471d in gui_container_t::zeichnen (this=<value optimized out>, offset=<value optimized out>)
at gui/gui_container.cc:123
#7 0x00000000004fcc1a in pakselector_t::zeichnen (this=<value optimized out>, p=<value optimized out>, gr=<value optimized out>)
at gui/pakselector.cc:85
#8 0x00000000005ab877 in ask_objfilename (argc=1, argv=0x7fffffffdae8) at simmain.cc:247
#9 simu_main (argc=1, argv=0x7fffffffdae8) at simmain.cc:651
#10 0x00000000006251e4 in main (argc=1, argv=0x7fffffffdae8) at simsys_s.cc:748
(gdb) quit
gdb simexp-DL-2010-05-24-c478903
Program received signal SIGSEGV, Segmentation fault.
0x000000000063334b in display_fillbox_wh_clip(short, short, short, short, unsigned short, int) ()
(gdb) bt
#0 0x000000000063334b in display_fillbox_wh_clip(short, short, short, short, unsigned short, int) ()
#1 0x0000000000496a02 in button_t::zeichnen(koord) ()
#2 0x00000000004acff7 in gui_table_t::paint_cells(koord const&) ()
#3 0x00000000004ad131 in gui_table_t::zeichnen(koord) ()
#4 0x00000000004ab4d3 in gui_scrollpane_t::zeichnen(koord) ()
#5 0x00000000004dcc97 in gui_container_t::zeichnen(koord) ()
#6 0x0000000000506b63 in pakselector_t::zeichnen(koord, koord) ()
#7 0x00000000005b9e79 in simu_main(int, char**) ()
#8 0x0000000000637fe4 in main ()
Both of these crashes are always reproducible and still happen after i fixed the problem of not having unpacked the config archive
Steffen,
thank you very much for the reports. It's very difficult for me to attempt to understand or fix issues that are specific to 64-bit Linux, as I only have a 32-bit Windows system on which to test. Can you see whether the 32-bit Linux version is stable for you? There are no performance advantages to using 64-bit for Simutrans. If 32-bit is stable, then it may simply be best to withdraw the 64-bit release for any purpose other than testing for the time being.
Well I encountered a couple of problems with the 32 bit version (but they're probably not 32bit-specific) but you've seen the other threads :)
Would it help if I bisect the particular commit that caused the breakage? It worked just 3 weeks ago and I saw an article somewhere once on how to get git to do this pretty much automatically.
Steffen,
yes, that would be very helpful indeed :-)
Ok it's not as easy as I thought it would be (it never is, is it lol) because a lot of the intermediary commits break building. So I went with manual bisecting after all but these links might help you (second one is about automating it, but I suspect Windows' batch files aren't really good enough for this task):
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
https://lwn.net/Articles/317154/
Now back to the topic, as I understand git the commit that breaks it is: e6f5d18dc509fc755152a832227f419c06ef0da4
But here's the relevant output as I'm not quite sure.
git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 steps)
[368327c96d7f1c950121a3dd9fb0951b4e5a0b9d] Mostly reverted 3155 as this gave problems with airplane shadows, ways are drawn in display_boden again
steffen@steffen ~/simutrans-git/simutrans-experimental $ cat .git/refs/bisect/bad
e6f5d18dc509fc755152a832227f419c06ef0da4
Edit: ??? I just decided to checkout the revision that I thought had worked but in fact doesn't. I'll try to figure out what I've done wrong now..
Thank you for your investigation. That commit is actually from Standard: the change is in simtypes.h as follows:
-return ((uint16)data[0]) | ( ((uint16)data[1]) << 8 );
+ /* according to C standard uint8 will be anyway extended to unsigned */
+ return (uint16)(data[0] | ( data[1] << 8 ));
Can you try the latest Simutrans-Standard code and see whether you have the same problem?
uint8 (typedef for unsigned char) gets promoted to int (see ISO/IEC 14882:1998(E) ยง4.5:1).
Tron,
does that mean that there is a bug in the Standard code in simtypes.h? If so, then I should post an official bug report there. Thank you very much for the information.
The code is fine for loading two bytes and concatenating them to a 16-bit value (****uming that int has more than 16 bits), if that's what you mean.
Forgive me for being silly, then: but what was the significance of your earlier post? I'm a little confused...
I just noticed the comment in the diff you posted. I did not realise, that this comment exists in the trunk of Simutrans.
Ahh, I understand now! Sorry for the confusion. Should the comment in Simutrans-Standard be changed, then...?