Config
Log for #openttd.dev on 22nd February 2014:
Times are UTC Toggle Colours
00:30:56  *** Supercheese has joined #openttd.dev
00:30:56  *** ChanServ sets mode: +v Supercheese
03:12:06  *** LuHa has joined #openttd.dev
03:12:06  *** ChanServ sets mode: +v LuHa
06:08:12  *** LuHa has quit IRC
06:47:31  *** Supercheese has quit IRC
08:51:33  *** Alberth has joined #openttd.dev
08:51:33  *** ChanServ sets mode: +v Alberth
13:12:31  *** frosch123 has joined #openttd.dev
13:12:31  *** ChanServ sets mode: +v frosch123
14:11:40  *** LuHa has joined #openttd.dev
14:11:40  *** ChanServ sets mode: +v LuHa
14:26:09  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26360 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:32:38  *** LuHa has quit IRC
18:45:29  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26361 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:58:55  <frosch123> wow
18:59:55  <frosch123> hmm, how boring
19:00:29  <frosch123> so, i replayed the desync files which pm saved. the dmp_cmds savegames from the orignal server and the replay match
19:01:10  <frosch123> so, either the desync really only started after the last dmp_cmds
19:01:35  <frosch123> or it affects something that is not part of the savegame at all
19:10:43  <frosch123> oh, not true, i compared the wrong files :/
19:14:52  <Alberth> hopefully with better results
19:15:06  <frosch123> yes, the first two saves match
19:15:09  <frosch123> that last pair does not
19:23:22  <Rubidium> evening
19:34:58  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26362 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:44:28  <Rubidium> http://rbijker.net/openttd/fs5894_worth_they_effort%3f.diff <- shouldn't change a bit, except being more explicit
19:49:04  <frosch123> looks safe
19:49:15  <frosch123> the invalid case cannot happen when extracting 2 resp. 1 bit
19:50:17  <Alberth> comment is a bit silly indeed
19:52:20  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26363 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
20:00:57  <fonsinchen> frosch123, I'll go and test your patches for FS#5867 now...
20:01:12  <fonsinchen> That means I'll be offline. Any final comments?
20:01:19  <frosch123> thanks :)
20:01:41  <Rubidium> @base 10 16 148
20:01:41  <DorpsGek> Rubidium: 94
20:03:36  <frosch123> hmm, what's the CMDL  hunk
20:03:47  <frosch123> cargomonitor
20:11:35  <frosch123> pff 60k of gamescript save data
20:28:25  <frosch123> http://paste.openttdcoop.org/show/3120/ <- difference of the last cmd_dmps from the public server desync
20:28:34  <Rubidium> @base 10 16 2980539799699456
20:28:34  <DorpsGek> Rubidium: A96C900000000
20:29:11  <Rubidium> definitely a wrong value for first_unused
20:29:32  <frosch123> basically two industries, stations and cargopackets differ in the amount of some cargo
20:31:02  <Rubidium> frosch123: FS#5831?
20:31:28  <Rubidium> their solution was to revert to the "broken" persistent storage
20:31:31  <frosch123> no, pm last weekend
20:31:50  <frosch123> 1.4.0-beta4
20:32:01  <Rubidium> frosch123: no, not that you are looking at FS#5831, but that it smells like the same thing
20:32:07  <frosch123> i took the start-savegame and cmd_dmp saves from planetmaker
20:32:32  <Rubidium> i.e. something with the persistent storage
20:33:04  <frosch123> hmm, ok, i'll check the 'closure_counter'
20:33:27  <frosch123> that should behave deterministaclly or something, it looks like it is incremented at defined places
20:45:13  <Rubidium> FS#5892 is weird
20:46:07  <Rubidium> if that jptracks newgrf is loaded in a debug build of that exact revision, then it crashes upon closing with a orderlist pool first_unused of HUGE (number of 21:28)
20:46:15  <Rubidium> however, the pool is completely empty
20:46:30  <Rubidium> if the NewGRF isn't loaded, nothing bad happens
20:46:38  <frosch123> valgrind?
20:46:59  <frosch123> or windows only?
20:47:21  <Rubidium> valgrind on Linux doesn't seem to trigger anything
20:47:45  <Rubidium> should check the actual revision though
20:48:02  <Rubidium> although today Windows nightly crashes in the same way
20:49:10  <frosch123> well, if it is windows only, it may very likely be fs#5867 which looks like a random invalid write to me
20:49:27  <Rubidium> yup
20:57:05  <Rubidium> @base 16 10 A96C9
20:57:05  <DorpsGek> Rubidium: 693961
20:57:14  <Rubidium> @calc 693961/365
20:57:14  <DorpsGek> Rubidium: 1901.2630137
20:57:21  <Rubidium> @calc 693961/365.25
20:57:21  <DorpsGek> Rubidium: 1899.96167009
21:06:06  <Rubidium> http://rbijker.net/openttd/fs5892.diff <- I have high hopes that fixes it
21:07:21  <frosch123> how?
21:07:44  <Rubidium> 	memset(this->railtype_map, INVALID_RAILTYPE, sizeof(this->railtype_map));
21:07:57  <Rubidium> 		if (rt == INVALID_RAILTYPE) return CIR_INVALID_ID;
21:08:13  <Rubidium> now INVALID_RAILTYPE = 0xFF
21:08:22  <frosch123> ah
21:08:25  <Rubidium> imagine that sizeof(RailType) != 1
21:09:47  <Rubidium> valgrind wouldn't notice because it's all in the global-allocated-at-start pool
21:10:14  <frosch123> looks nice .)
21:12:34  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26364 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
22:32:59  *** Alberth has left #openttd.dev
23:13:09  *** frosch123 has quit IRC
23:17:43  <fonsinchen> Well, with those new insights about FS#5867 I'll look at the code again with a less claustrophobic editor tomorrow to see if and where those cursor sprites are actually changed.

Powered by YARRSTE version: svn-trunk