Cargo Distribution

[huldu]

The one i got was a page or two back in this thread, according to version it is r18368M. Ill see if i can find some other build to use. No crash logs whatsoever ive searched everywhere in the game folder and in the documents folder.

<edit> Yeah, im using the one by terkhen.
<edit2> I apparently found a reliable way to cause the crash, but could just be luck. Anyway i did find a dump but it is probably the wrong one. This was created when the application crashed in the \temp folder. I tried get the bigger dump file but windows locks it and delete it as soon i click "close". But its also probably not the right one. Windows dumps are useless right? I just dont understand why the game wont create a crash file, is there some setting not right?

<edit3> I have always caused the crash by building a few airports and airplanes within a few minutes of a game it crashes. Last game where i didnt use airports the game went on fine for a few hours then crashed as i built an airport and started using it. Pretty sure i had a crash the other night tho where i didnt even have any airports at all. But yeah, its weird its so easy to get the game to crash just by placing a few airports and have a few airplanes travel between them.

[Creat]

Well I shouldn't have said anything, we've been continuing a game tonight and had two crashes. The latest auto saves from just a minute or two before the crash are attached (see their description). Unfortunately I don't have any crash.dmp either for unknown reasons. My version is compiled with MSVC (my own build) from a (usually recent) straight git checkout. In this case my version is g809770f1, which was the latest a couple of hours ago.
I'm running on Win7 x64 here. Windows seems to intercept the crash and 'checking with Microsoft for a solution to the problem' (or something similar), could that preempt the internal crash handler? Nothing comes of it (obviously). This still doesn't explain though why huldu doesn't get a crash dump either though (since it's WinXP)...

One file is created by the MS handler, but it isn't exactly helpful, I've attached it anyways...
C:\Users\{username}\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_openttd.exe_2025b513177b5f96baa5d1f5865933bb78501c37_10d02b74\Report.wer

edit: had to zip it, since the forum refused to accept a .wer file...

[Roujin]

In trunk ~r18405, drive through road stop behavior was drastically enhanced Can't wait for a sync of cargodist, since I love to build tram networks inside cities in my cargodist games.

[NekoMaster]

In trunk ~r18405, drive through road stop behavior was drastically enhanced Can't wait for a sync of cargodist, since I love to build tram networks inside cities in my cargodist games.

How is it enhanced?

[Roujin]

In a lot of ways:
If there are multiple road stop parts to choose from, the vehicle now makes a better choice (from commit logs only, didn't test that one).
Also, vehicles need less space for themselves now in a DTRS. Two (standard length) vehicles can now load simultaneously per tile (in the same direction, behind each other. of course in the other direction another two can load at the same time)
Also, behavior was improved when there's already a queue of vehicles waiting at a multi-tile DTRS. Previously, it would often happen that the DTRS was cleared from front to back, and then the first vehicle of the waiting queue would not drive through to the front, but rather taking the very last tile of the DTRS, blocking off all the other vehicles waiting behind. This now doesn't happen anymore.

In summary, throughput is a lot more fluent now for overcrowded (with vehicles) drive through stations.

[fonso]

As usual I can't reproduce any of the crashes. I have one of the crash saves running in valgrind now for about 3 hours and there's nothing suspicious so far. I also don't understand why there are no crash logs or dumps. It'd be really great if one of you could try to get me a backtrace by running the game in a debugger - MSVC has one for example. As soon as I have a backtrace I can probably guess what's wrong and if not I can at least try to artificially provoke the same situation in order to find out more.

[Creat]

The problem is that it isn't reproducible here either, usually when it does crash loading an auto save (even if it was made just seconds before the crash) fixes everything and the game runs fine for hours.

EDIT: Ha, finally managed to reproduce the crash with the debugger attached. This crash occurs less than a minute after loading crashsave1 from my last post (with version g809770f1), to be more precise on december 9th 1950, when clicking on (or having open) "train details" of train 4 (in station 'Coal Mine 1' at the time).
This also shows pretty clearly that the crash handler is invoked, so why the hell isn't a crash dump generated?

Since this isn't a debug build there isn't exactly a lot of information I can give you beyond the call stack below, I'll try again with a debug build...
Also in case that helps I can upload my build/pdb (x64) should you still be unable to reproduce, but you should be able to make an identical build with a checkout of he version mentioned above...

Code: Select all

openttd.exe!__crt_debugger_hook(int _Reserved=12)  Line 65	C
openttd.exe!_invalid_parameter(const wchar_t * pszExpression=0x0000000004daf4b0, const wchar_t * pszFunction=0x0000000000000001, const wchar_t * pszFile=0x00000000056205b0, unsigned int nLine=22, unsigned __int64 pReserved=0)  Line 114	C++
openttd.exe!_invalid_parameter_noinfo()  Line 126	C++
openttd.exe!GetCargoSummaryOfArticulatedVehicle(const Train * v=0x000000000000000e, SmallVector<CargoSummaryItem,2> * summary=0x0000000004daf4b0)  Line 239 + 0x43 bytes	C++
openttd.exe!GetTrainDetailsWndVScroll(unsigned short veh_id=37520, TrainDetailsWindowTabs det_tab=92705424)  Line 287	C++
openttd.exe!VehicleDetailsWindow::OnPaint()  Line 1534 + 0xf bytes	C++
openttd.exe!DrawOverlappedWindow(Window * w=0x0000000005869290, int left=24, int top=320, int right=320, int bottom=152)  Line 445	C++
openttd.exe!RedrawScreenRect(int left=1408, int top=0, int right=720, int bottom=30161218)  Line 1414 + 0x53 bytes	C++
openttd.exe!DrawDirtyBlocks()  Line 1500 + 0x5 bytes	C++
openttd.exe!UpdateWindows()  Line 2222	C++
openttd.exe!VideoDriver_Win32::MainLoop()  Line 890	C++
openttd.exe!ttd_main(int argc=0, char * * argv=0x000000013f8ef1a0)  Line 738	C++
openttd.exe!WinMain(HINSTANCE__ * hInstance=0x0000000000000000, HINSTANCE__ * hPrevInstance=0x0000000000000000, char * lpCmdLine=0x0000000000000000, int nCmdShow=0)  Line 381	C++
openttd.exe!__tmainCRTStartup()  Line 263 + 0x21 bytes	C
kernel32.dll!0000000076d3f56d() 	
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
ntdll.dll!0000000076e73281()

[fonso]

I usually have cargodist run in the debugger "just in case". When it crashes I can just type "bt" and see the backtrace. This is very convenient. Of course it makes the game slower. But the saves you're posting here aren't that large anyway.

[Creat]

MSVS generally allows me to attach the debugger 'post mortem', so there isn't any need for that. But ever since Win7 this 'checking with MS for a solution' (which I've just disabled) takes such a long time - meaning minutes - and it only offers to attach the debugger afterwards that I usually don't bother...

PS: Don't overlook my report above, didn't want to double post but you were faster in replying ^^

[fonso]

Wow, lots of memory corruption:

Code: Select all

openttd.exe!RedrawScreenRect(int left=1408, int top=0, int right=720, int bottom=30161218)  Line 1414 + 0x53 bytes   C++

This shouldn't be possible as bottom is clamped into screen height.

Code: Select all

openttd.exe!GetTrainDetailsWndVScroll(unsigned short veh_id=37520, TrainDetailsWindowTabs det_tab=92705424)  Line 287   C++

The vehicle ID should be 191 for train 4. There are only 211 vehicles in this game. TrainDetailsWindowTabs is an enum. Its integer representation should be between 0 and 3.

Code: Select all

openttd.exe!GetCargoSummaryOfArticulatedVehicle(const Train * v=0x000000000000000e, SmallVector<CargoSummaryItem,2> * summary=0x0000000004daf4b0)  Line 239 + 0x43 bytes   C++

Of course the "const Train * v" pointer is invalid. That's because of the invalid vehicle ID before.

My guess is that some other function writes junk all over the heap. At least I don't see any other possibility of writing a wrong bottom value into _invalid_rect. It would also explain the nondeterminism of those crashes. Unfortunately that's still quite hard to debug without a possibility to reproduce it. I had that exact savegame running in valgrind this morning. And it didn't find any memory management problems. But I didn't actually use the GUI a lot so a different window might be responsible for the mess.

Creat, did you use any other windows between loading the game and the crash?

[Creat]

Nope, I knew I clicked on some train at the mentioned station and went to the Tran Details window (to check which engines I was using). This is now 100% reproducible for me with the following steps:

• Start OpenTTD and load the crashsave1.sav
• Open the Train Details window for train 4 (as far as I know it doesn't matter at all how you open the train window, via train list or just clicking on it)
• Wait a few seconds and OpenTTD crashes, if not right away

Interesting: There is a relatively short window in which this crashed OpenTTD, apparently whatever is corrupted fixes itself after some time, making this a real sob to catch... So if you wait or take too long to open the window it just won't crash anymore.

[fonso]

OK, finally I can reproduce it. Only in windows, though. Let's see if I can wrap my head around the MSVC debugger ...

[fonso]

I have found the crash (at least the one Creat was suffering from). The problem was related to cargo reservations. As both reserved packets and "onboard" packets are accounted for in vehicle cargolists' caches the assumption that "count > 0" means that there are packets in the "onboard" list is not necessarily true anymore. The bug is fixed in the latest version available at the usual places. Thanks for your patience and for all the bug reports.

[petert]

Great! I will make another build tommorow...

[huldu]

How do i start the "debug" build? Im guessing my crashes are caused by the same thing above. The only difference is that the crashes happen pretty much all the time when i start building airports and send planes between them.

[Roujin]

Sweet, sync with trunk included
Hope the saves from my last cargodist game are still compatible...

[Terkhen]

Another MSVC release cargodist build, using the patch against r18412. If you experience a crash, upload your crash.log and crash.dmp to this thread. These files can be found whenever openttd.cfg is; in Windows Vista / 7 the standard folder is (User folder)\Documents\OpenTTD. Explaining what you were doing before the crash and uploading your latest savegame will also help fonso but these two files are vital. Remember that the PDB file is only for debugging purposes: you don't need it to test cargodist.

Edit: Build updated.

[fonso]

Roujin: No, the savegames aren't compatible. There has been a savegame version bump in trunk, I'm sorry.

huldu: In MSVC there is a dropdown in the menu where you can select between "Debug" and "Release". If you select "Debug" and build you get a debug build. That doesn't mean it deletes the Release build though - you can have both at once. When you run or debug it from MSVC, it sort of starts the variant you have selected in that dropdown. Better check in the console output, though - sometimes it starts the other one.
And don't ask me how to properly package that thing ... I messed it up twice, I won't try again. Other people are better at that (thanks Terkhen ... )

[NekoMaster]

Hey thanks Terkhen :3 I hope it doesnt crash to much :3

[Terkhen]

About "Release" and "Debug" builds: if you are talking about enabling debug output launching OpenTTD with the "-d" option, you can do that too with Release builds, but it is enabled by default only in "Debug" builds.

I use a batch file to package MSVC builds easily. It must be run at the root folder of your checkout, and only packages Release builds (to make it package Debug builds instead, change the "Release" folder for "Debug". This is the code:

Code: Select all

@echo off
mkdir bundle
erase /F /S /Q bundle\*
copy objs\Win32\Release\openttd.exe bundle
xcopy /S /Y bin bundle
copy COPYING bundle
copy changelog.txt bundle
copy known-bugs.txt bundle
copy readme.txt bundle

Edit: If you are using gnuwin32 coreutils, you can replace "erase /F /S /Q bundle\*" for "rm -rf bundle\*". This is more clean because it removes directories too.