Regression in 8.0 - segfaults on start on linux64 May 28, 2010, 10:38:01 pm 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:30953095 *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) quitgdb 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 () Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #1 – May 29, 2010, 10:31:33 pm Both of these crashes are always reproducible and still happen after i fixed the problem of not having unpacked the config archive Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #2 – May 29, 2010, 11:13:57 pm 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. Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #3 – May 29, 2010, 11:33:41 pm 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. Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #4 – May 29, 2010, 11:42:43 pm Steffen,yes, that would be very helpful indeed :-) Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #5 – May 30, 2010, 05:17:30 pm 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.htmlhttps://lwn.net/Articles/317154/Now back to the topic, as I understand git the commit that breaks it is: e6f5d18dc509fc755152a832227f419c06ef0da4But here's the relevant output as I'm not quite sure.git bisect badBisecting: 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 againsteffen@steffen ~/simutrans-git/simutrans-experimental $ cat .git/refs/bisect/bad e6f5d18dc509fc755152a832227f419c06ef0da4Edit: 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.. Quote Selected Last Edit: May 30, 2010, 05:31:08 pm by steffen
Re: Regression in 8.0 - segfaults on start on linux64 Reply #6 – May 30, 2010, 05:48:07 pm Thank you for your investigation. That commit is actually from Standard: the change is in simtypes.h as follows:Code: [Select]-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? Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #7 – May 30, 2010, 09:58:03 pm Quote from: jamespetts – on May 30, 2010, 05:48:07 pmThank you for your investigation. That commit is actually from Standard: the change is in simtypes.h as follows:Code: [Select]-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 ));uint8 (typedef for unsigned char) gets promoted to int (see ISO/IEC 14882:1998(E) ยง4.5:1). Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #8 – May 30, 2010, 11:17:34 pm 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. Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #9 – June 01, 2010, 05:31:28 am 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. Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #10 – June 01, 2010, 09:34:25 am Quote from: Tron – on June 01, 2010, 05:31:28 amThe 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... Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #11 – June 02, 2010, 06:26:34 pm I just noticed the comment in the diff you posted. I did not realise, that this comment exists in the trunk of Simutrans. Quote Selected
Re: Regression in 8.0 - segfaults on start on linux64 Reply #12 – June 02, 2010, 07:22:28 pm Quote from: Tron – on June 02, 2010, 06:26:34 pmI 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...? Quote Selected