Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random game crash #6688

Closed
DorpsGek opened this issue Mar 19, 2018 · 13 comments
Closed

Random game crash #6688

DorpsGek opened this issue Mar 19, 2018 · 13 comments
Labels
bug Something isn't working component: ICU Issue caused by problems with ICU layout flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

bnegrut opened the ticket and wrote:

Random game crash

OS Windows 10, 64 bit
Game version 1.7.2. 64 bit

Crash at: Mon Mar 19 19:27:44 2018
In game date: 1922-10-08 (16)

Crash reason:
Exception: C0000005
Location: 00007FF70AAB5440
Message:

OpenTTD version:
Version: 1.7.2 (0)
NewGRF ver: 17286d2d
Bits: 64
Endian: little
Dedicated: no
Build date: Dec 24 2017 12:25:35

Attachments

Reported version: 1.7.2
Operating system: Windows


This issue was imported from FlySpray: https://bugs.openttd.org/task/6688
@DorpsGek
Copy link
Member Author

bnegrut wrote:

Crashed again today. DMP file will not upload.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6688#comment14876

@DorpsGek
Copy link
Member Author

3298 wrote:

From the crash.log of both crashes:
Tick 14454: GRF config changed
Removed NewGRF: GRF ID 52455400, unknown GRF
There is a reason changing NewGRFs is hidden behind a openttd.cfg-only option and displays a red warning window (which should also have told you NOT to report issues that happen after you do so): Changing NewGRFs can wreak all kinds of havoc in a savegame, including setting it up so it crashes later. That appears to be what happened here, so ... warranty void, I guess.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6688#comment14877

@DorpsGek
Copy link
Member Author

bnegrut wrote:

Now I understood that the cause is a GRF, specifically GRF ID 52455400, checksum 1600687C50C5AB1E72EDD487CAD50E2A, filename: coded_by_aegir._artwork_by_aegir-1/ae_cityw.grf (md5sum matches).
What I can not understand is why a GRF that is not loaded cause such havoc. Also, as far as I remember I did not load it for this game. Is there a way to check if this GRF was loaded at some point in the game?

Attached is a screenshot with the GRFs in use in game.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6688#comment14878

@DorpsGek
Copy link
Member Author

3298 wrote:

That would be the gamelog, which got thrown into both crash.log files. As far as I know, there's also a console command that outputs the gamelog of a running game, but why bother with that when it's right there. - It's the section I took those lines from. The rest of the gamelog tells me that the game was started with all the GRFs I see listed in your screenshot plus that missing one at the end of the list, using version 1.7.1. On tick 1280 (approximately in-game day 18) you switched to version 1.7.2. On tick 14454 (approximately day 192, i.e. after almost six and a half in-game months) the GRF got removed. The gamelog section of both crash.log files is identical, so I guess that after you experienced the first crash, you reloaded a save that was made after the GRF was already removed (e.g. the emergency save created during the crash).
I'm not the developer of that GRF (or even a GRF dev at all), so I don't know how it's coded (and I'm not familiar with OpenTTD's NewGRF handling code either) and therefore don't know if the following even has a chance of working, but my first attempt at fixing this savegame would be adding the GRF back (at least you were able to identify the missing one, so there's that). Considering that it's a fairly old and possibly a relatively simple GRF just providing station graphics, it might just work, but that's unfortunately far from guaranteed.
GRFs are deeply integrated into the system, so they can have great influence on the game state. When GRFs are changed, a lot of lists get updated, but when the stuff in the lists has been used already, we are screwed. Then some hilarious things can happen, like lone helicopter rotors swimming across the ocean, or a coal plant's exhaust plume pulling into a bus station. But things can go more wrong than that - try loading passengers into that exhaust plume, for instance. They'll probably choke, as does the game that assumed the plume was a bus instead. Though I can't think of a reason why the absence of a station set would lead to a crash (and I can't check the stacktrace to see what the game was doing, because unlike Linux, Windows stacktraces need tools to decipher), there appears to be one.


This comment was imported from FlySpray: https://bugs.openttd.org/task/6688#comment14879

@DorpsGek
Copy link
Member Author

bnegrut wrote:

New Game, without changing any GRF, still crash.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/6688#comment14882

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
@TrueBrain TrueBrain added needs triage This issue needs further investigation before it becomes actionable bug Something isn't working and removed bug from FlySpray labels Apr 11, 2018
@frosch123 frosch123 removed the Core label Apr 14, 2018
@bnegrut
Copy link

bnegrut commented May 4, 2018

Another new game. Still random crash.

crash.log
crash

@glx22
Copy link
Contributor

glx22 commented May 5, 2018

Without the dmp it will be impossible to trace the crash.

@janisozaur
Copy link
Contributor

Out of curiosity: why is the provided stack trace insufficient?

@glx22
Copy link
Contributor

glx22 commented May 6, 2018

Because, for some reasons, the provided stack trace is not decoded. and with just the addresses it's hard to know where the crash happened.

@bnegrut
Copy link

bnegrut commented May 6, 2018

Unfortunately, i can't upload the .dmp file.
It is available here https://drive.google.com/drive/folders/1yaz_diStSmebXJpz2sG9yakPrXxCx5eU?usp=sharing. Please let me know if you can access it.

Thank you

@janisozaur
Copy link
Contributor

@glx22 yes, I saw, but you didn't answer my question. To rephrase what I meant: why can't you load the process in a debugger, attach the symbols and symbolise the trace? Or just symbolise it with stack walker, skipping the debugger?

@bnegrut as long as it is smaller than 10MiB, GitHub will accept files with names ending in .zip, .txt, .jpg, .png, so renaming or packing should suffice.

@bnegrut
Copy link

bnegrut commented May 6, 2018

Understood.
Reattached, as an archive.
crash.zip

@glx22 glx22 added component: ICU Issue caused by problems with ICU layout and removed needs triage This issue needs further investigation before it becomes actionable labels May 6, 2018
@andythenorth
Copy link
Contributor

Thanks. ICU has known issues, and there is a project underway to replace it. We're not keeping the reports relating to it open, but they can still be found here as and when they are needed. Thanks for the report and diagnosis efforts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working component: ICU Issue caused by problems with ICU layout flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

7 participants