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..
Ok I tracked down the sprawl a little further, it only happens for a certain time period. If a make a game start 1929 or earlier its ok (well, I think density is lower than usual in the 1920s, but it doesn't go mad) or if I start a game in 1950 or later its also ok. Just those two decades in between it's being funny with me.
I also got the cycling crash once last night but I didn't have gdb running.
files.simutrans-germany.com didnt work (it just kept saying the file already exists) so I put it on my own server https://schaumburger.info/steffencrash.sve Ignore the SSL warning. To crash it: Load the game, then try to view e.g. any of these stations: 466,738 (southampton), 687,901 (manchester-l) or 348,335 (leipzig-w). If you open 676,909 (manchester-k) it shouldnt crash.
This (and all my other reports except the one about the 64bit versions not starting) happens with the 32bit version of experimental 8.0. Edit: From the download site that is
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.
I just tried on a brand new map to switch between the display mode (amount, via, etc.) on a station and for me it doesnt crash (32bit, running in gdb).
urban sprawl: I tried setting "rennovation_percentage" and "renovation_percentage" (had to create a new entry as there was no default one in there) in Pak128.Britain-Ex/config/simuconf.tab but it doesn't seem to have had any effect
Moderator note: split the topic, as this relates to a different bug report. Please always post one topic for each different bug.
Ok another problem tho, if I try to open (as in, just view) some of my train-bus stations it reproducibly gives an immediate segfault. It doesn't happen on all stations tho. I tried to reproduce it on a new map with a double station with a bus stop attached but it didnt crash.
E.g. on southampton it happens, on manchester-k it doesnt happen but on manchester-l it does. All three stations are the same type of platform on the same type of track. Southampton and Manchester-k are double plattform (one in each direction) whilst Manchester-l is the turnaround end station. All three have bus stations attached. I really can't think of an explanation for this pattern.
Here's one of the segfaults: Program received signal SIGSEGV, Segmentation fault. 0x080ca109 in freight_list_sorter_t::compare_ware(ware_t const&, ware_t const&) () (gdb) bt #0 0x080ca109 in freight_list_sorter_t::compare_ware(ware_t const&, ware_t const&) () #1 0x080cb557 in void std::__introsort_loop<ware_t*, int, bool (*)(ware_t const&, ware_t const&)>(ware_t*, ware_t*, int, bool (*)(ware_t const&, ware_t const&)) () #2 0x080ca66f in freight_list_sorter_t::sort_freight(vector_tpl<ware_t> const*, cbuffer_t&, freight_list_sorter_t::sort_mode_t, slist_tpl<ware_t> const*, char const*) () #3 0x081edca4 in haltestelle_t::get_freight_info(cbuffer_t&) () #4 0x0812a859 in halt_info_t::zeichnen(koord, koord) () #5 0x08236105 in display_win(int) () #6 0x082364bc in display_all_win() () #7 0x08236760 in win_display_flush(double) () #8 0x08200f58 in intr_refresh_display(bool) () #9 0x08243f9f in karte_t::sync_step(long, bool, bool) () #10 0x08200efc in interrupt_check(char const*) () #11 0x0824ec23 in karte_t::interactive(unsigned int) () #12 0x0820a663 in simu_main(int, char**) () #13 0x0828e751 in main ()
You were kind of right, turns out it was because initially I hadn't installed the files from the config download. The loading works now, but the other things I wrote about in other threads still happen.
I'm having a problem loading my savegame from 7.3 (git from 8may) with the 32bit build on linux. The savegame was created with 64bit. I can't attach the savegame because its over a MB but I can mail it if you want. I'm not actually bothered by this but thought I should mention it.
Here's what it says: FATAL ERROR: fabrik_t::rdwr() no besch for FishPort1945
I can confirm the urban sprawl problem with the 32bit version on a 64bit system. After city generation with timeline from 1945 a city of 40k people took up half the screen at maximum zoom at 1920*1080.
Bit late but I think this is a great idea. Just a couple of comments I think having the second date relative to the first one (as in write "10 years" rather than "1965") is a good idea, it doesn't make it any harder to change the second date, but it does make it easier to change the first one. This will probably avoid many accidental errors in this regard. I also like the idea of higher prices at the beginning of a vehicles production/use but it does make it harder at the beginning. So ideally it should come with an off-switch
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 ()
Well replacing the forum with a bugtracker would definitely be a bad idea, but having it additionally might be worth considering. OTOH if the current system works well - "never touch a running a system"
This reminds me why I use Python for my own programs lol. In any case I found another reproducable segfault, but I'll post it as a new thread since it appears to be a different issue.
yes you're right, I found that activating NEW_PATHING lets the program run fine, whilst OPTIMISE breaks it. Now I looked in the Makefile and the only conclusion I can draw is that it's a toolchain bug. If anyone agrees I'll head over to GCC and post a bugreport.
ansgar: in the meantime, can you deactivate OPTIMISE for the amd64 autobuild?
Ok it seems I found what causes the segfault on startup with the autobuild. It's either OPTIMISE = 1 or -DNEW_PATHING. Here's the backtrace for a start, I'll try which of these the final culprit is now and then try it with devel. I realise now that I should've tried devel first, didn't take into account that these flags can influence which code is compiled *sigh*
Program received signal SIGSEGV, Segmentation fault. 0x000000000062997b in display_fb_internal (xp=<value optimized out>, yp=<value optimized out>, w=<value optimized out>, h=88, color=<value optimized out>, dirty=<value optimized out>, cL=<value optimized out>, cR=<value optimized out>, cT=0, cB=<value optimized out>) at simgraph16.cc:2959 2959 *lp++ = longcolval; (gdb) bt #0 0x000000000062997b in display_fb_internal (xp=<value optimized out>, yp=<value optimized out>, w=<value optimized out>, h=88, color=<value optimized out>, dirty=<value optimized out>, cL=<value optimized out>, cR=<value optimized out>, cT=0, cB=<value optimized out>) at simgraph16.cc:2959 #1 0x0000000000629aee in display_fillbox_wh (xp=44, yp=176, w=20338, h=1, color=<value optimized out>, dirty=-135966870) at simgraph16.cc:2990 #2 0x00000000004d6c1b in gui_frame_t::zeichnen (this=<value optimized out>, pos=..., gr=<value optimized out>) at gui/gui_frame.cc:155 #3 0x00000000004fe59c in pakselector_t::zeichnen (this=0x2c, p=..., gr=<value optimized out>) at gui/pakselector.cc:64 #4 0x00000000005aa74e in ask_objfilename (argc=1, argv=<value optimized out>) at simmain.cc:247 #5 simu_main (argc=1, argv=<value optimized out>) at simmain.cc:644 #6 0x000000000062dc67 in main (argc=1, argv=0x7fffffffdac8) at simsys_s.cc:743 (gdb) quit
No, no, the autobuild might have ccache installed, and that may be causing breakage there.
Ah ok, yes that could be a cause. But the bug linked appears to be specific to Gentoo's handling of having two-in-one platforms, and was marked fixed (by update to an ecl****, which are again Gentoo-specific) more than a year ago. But I guess until proven otherwise we should consider that an option.
Sourceforge has a bugtracking system for projects, that could be used. I definitely think it's a good idea to have one. I reckon some types of people can be quite motivated by the more structured approach of a formal bug tracker. Maybe it'll be used, maybe not - but it only takes a few clicks by a simutrans project admin to activate so I think it's worth a shot. There's also some functions that simply can't be replicated by using a forum, e.g. dependencies and meta-bugs. A bugtracker also makes things easier to follow, e.g. one can see straight away if a bug only affects a certain platform, whether it affects just std or just exp or both, etc. As for the mouldering bugs.. there could be a "policy" to simply close bugs with a standard notice once they haven't seen activity in say 3 months. Then if the reporter (or anyone else) finds that the bug is in fact still existent it can always be re-opened. And if nobody can be bothered to perform this task - who cares. Anyone who actually tries simutrans will see it's a great game, irrespective of the open bug count
Good idea but I don't have ccache installed so that can't be it I'm not sure if you understood me right, my own build appears to work fine (it loads with the experimental britain pak, it loads my save game originally made with the i386 autobuild, I tried running it a couple of minutes) but the autobuild segfaults before it even asks me which pak I want to use. So we can exclude my run-environment, the actual code and the pak as sources of the problem with the autobuild. (I refer to the problem that it doesnt even launch, the problem in vector-tpl.h
Now of the top of my head I can think of these remaining suspects: - lack of DEBUG in the 04-11 autobuild causes the problem - some other difference between sdog's and mine vs. the autobuild config causes it - the versions of GCC/libraries used in autobuild cause it - the versions of GCC/libs used during compile is incompatible with the versions used by sdog and me.
Not knowing much of C the last two are my favourites right now, so I'm emerging the old libraries.
sdog: I think it might be worth opening a new thread for the segfault you discovered during running your own build. I think it's save to ****ume that that is a different fault then whatever is causing the autobuild to segfault on startup.
Then I'm really confused, how can it be that the auto-build segfaults but my own build works? What exact settings (and GCC and library versions) are used to make the autobuild, I could try rebuilding with those to try and reduce the number of possible causes.
Good question, I never told git specifically so I would ****ume its the master branch. Here's the command I used: git clone http://github.com/jamespetts/simutrans-experimental.git Which branch is used to create the automatic builds?
Ok it seems the self-compiled version runs just fine. I confirmed with file that its a 64 bit version. Can you confirm that the 2010-04-11-fd32563 is the same as the latest git from http://github.com/jamespetts/simutrans-experimental (last date of change is April10, the commit ID conspicuosly starts with fd32563)? I'm really confused.. does anyone have any ideas?
For USE_C, could you add a note of this to config.template? As for the debug part, that looks like a typo in config.template, can you change it in there?
But with these two changes it now compiles, thanks
For all future bug reports I'll be sure to check both std and exp Back on topic, a quick diff between the latest exp git version and the latest std svn version reveals 7 pages of differences.
Ok I got the latest svn from svn://tron.homeunix.org/simutrans/simutrans/trunk and am getting the same error, but oddly in a different line: ===> CXX simgraph16.cc g++: unrecognized option '-NDEBUG' simgraph16.cc: In function ‘void rezoom_img(image_id)’: simgraph16.cc:1290: warning: comparison between signed and unsigned integer expressions simgraph16.cc: ****embler messages: simgraph16.cc:2370: Error: suffix or operands invalid for `jmp' make: *** [simgraph16.o] Error 1
I just installed gcc-4.4.3-r2 and I tried make clean && make but same problem. I'm installing gcc-4.3.4 now as well just to see if thats the problem.
Oh and just for the record I completely agree that 64bit should be lower priority, but its nice and I think also important in the medium-long term to keep going at it with low priority
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..
