Discussion in 'Bugs and Crashes' started by Lucibear, Mar 11, 2020.
Upload your User Settings too - its in Caveman2Cosmos folder.
It doesn't crash for me, since it's repeatable for you it either mean it is userSetting specific or system specific (probably linux/wine specific). We can check one of them easily if you upload your UserSettings folder.
I have put everything that looks like it could be settings or configuration in this zip.
Didn't make a difference.
What about your vanilla game options:
Have you made any custom changes to the ini file in " ...\Documents\My Games\Beyond the Sword\CivilizationIV.ini " ?
Just trying to find out if it indeed is a linux specific issue, I haven't looked at your minidump file as I've never done that before, thunderbird has though, so I'm leaving it for him for now.
I wouldn't need the minidump file to debug it if I could repeat the crash though.
C2C seemed to just copy the settings over, but I will provide the ini file so you can see whether it causes the crash. The only modification I did to the ini file directly was to set "mod = Mods\Caveman2Cosmos", so everything else was set by the game.
It is a bit steam specific, I have the GOG version, though if you didn't make any other changes than that then I'm pretty sure it shouldn't make a difference for this crash, default values here shouldn't be a problem.
Those vanilla options I screenshot aren't in the ini file though, I would need to see a screenshot of those options from you and try replicating the crash with the same settings.
I don't get anything useful from the mini really... it just says
Which is what happens most of the time when I run the mini with only the exe and pdb on the specified version number - I used to get results I could work with when I could run it with the minidump file inside the Sources->final_release folder IF the final release had not been rebuilt since the mini was created. That is completely impossible now since we don't actually post that whole build folder to the SVN. It was even only possible back then up to the point that the mini came in before I had created a new dll for any reason. You can get sometimes a bit more information from running the minidump in the assets folder where the dll and pdb are located, and only if it's on the exact SVN version, which according to what was posted, I did here, revision as stated,
But as you see I get no useful information. This could easily, however, be a problem that is very specific to linux as well and that could be a contributing factor. I'm just guessing here, but a violation in reading a location in memory could be related, though that's a common crash reason for numerous causes, one of which could well be a general MAF issue - this will happen if memory has run out and thus the reference call was incorrect because the location doesn't exist. But it doesn't have to be that either - it could be the kind of thing when you ask for information on a unit that has been deleted from the game for example. That was a very common problem at one point here and there's probably still places where it is. Unfortunately, without finding a repeatable crash in this case it's going to be very difficult to debug.
I have to admit I mostly did this to remind myself why I thought it was nearly impossible now to get a mini to be of any value... now I remember.
Here's the C2C settings:
and the vanilla settings:
C2C and vanilla settings are the same, can't be different, just so you know, they are attached to your profile which in your case is just named "Default Profile".
Ok, I tested with these settings + your UserSettings folder and it still wasn't repeatable.
I'm 99% certain that this repeatable crash is system specific.
You should turn off "low resolution textures" btw, it causes graphical glitches with the animal team flag art.
Interesting to see that you don't have the BtS font in your game, the game font is very much tied to the OS so it's probably caused by your linux/wine setup.
I've seen the font you have in my game before when I tell the game to use a font not installed on my windows 10 system (when I have a typo in the font name specified for it).
Example of the BtS game font:
I wonder if you get any interesting errors if you try launching the game with an assert build of our dll, I'll build one and give it to you if you are interested in checking it with me.
Here it is, screenshot asserts you get during launch of the game if any.
If you don't get any there perhaps it may be interesting to see what asserts you get when you end turn after sending the exile to babylon, I got none, but it also didn't crash for me. An assert will pause all game code processing, so if there are any before the crash the crash will be delayed until you close the last assert during the end turn.
Edit: overwrite the file within the assets folder in C2C.
So when I boot up the game and it's loading all the python and XML stuff it gives me a bunch of failed asserts that have to do with loading animation graphs. I assume these issues have been happening the whole time for me and I've just not noticed, so no big deal.
When I boot up and tell the exile to go to babylon, the game doesn't crash. I haven't played any further than telling what the city to build so I don't know if the problem is entirely gone.
Just as a quick test I reloaded the save (just hitting esc then load game), and it did crash in the same place it had before. No failed assertions, just a quit to desktop like with the regular dll. I'm not too surprised by that because other threads have warned about loading saves multiple times without reloading the game to cause issues.
I tried the above twice and saw nearly the exact same behavior. Maybe the regular dll causes some state that is similar to having loaded a previous save? I wouldn't know.
Ok, you shouldn't get any asserts when launching the game, at least no one on a windows system gets assert on launch. What do they say specifically?
I tested the save on the regular SVN dll without getting the crash, so your crash is still system related as far as we know.
The SVN dll is a finalRelease dll that has a lot of compilation optimization in it, it may be that some of those optimizations doesn't play well with your linux setup, which may explain why you don't get the crash with the assert dll.
If that's the case then my suggestion to you is that you set up C2C through git so that you get access to our dll compile scripts (bat files). In the git setup you will be able to update to latest version whenever you want and just start the game, and the game will recompile the dll on game launch if the dll code has changed since you last compiled one, it will also remember what dll variation you last used.
We have multiple dll variations:
FinalReleaseDLL (SVN takes long time to compile very optimized result)
AssertDLL (gives asserts during game play which is not ideal when you just want to play the game)
DebugDLL (you don't want this for regular play everything is slow with it)
ReleaseDLL (This one doesn't have asserts or debug code, but it's not heavily optimized like the finalRelease, still quite good performance though, and fast to compile. This would be the one you want as it may get you past some of the linux specific crash-points)
This is the assert window that I have been getting when I open the game:
View attachment 559542
Having now looked at CvInfos.cpp, holy cow that's a big cpp file. I usually think 500 lines is pushing it, and I typically try to split up cpp files once they get to even 300.
As for building the dll's myself, I don't really know how I would set that up. I'm sure if I spent enough time poking at it I could figure out. I've gotten too used to more unix style build systems that makes the C2C git repository pretty foreign to me.
It would be useful if we could get some info about Lucibear's setup, because if he was running using proton or wine (which, not that I'm thinking about it, isn't out of the question) then it would be clear that that is the culprit. But if not, that could point to a much deeper issue.
Something I could do to help debug is turn on proton logging. I with I thought of that sooner.
So I attached a couple of files. One of them is the log file generated by proton, and the other is that same log file that I ran through grep to get strings so that it is more readable. I'll probably stop trying to solve the issue here though unless you guys see some other way of going about debugging this or I suddenly come up with the solution in my sleep.
I really know absolutely nothing about linux or anything related unfortunately, except to say I think there was talk about wine? Somewhere?
Ends with "No Buildable Unit for selected AI!!" three times. That sounds helpful...
That happens every game over and over. It's one of the many things that should have been fixed when it started happening.
In this file they happen only two other places, both towards the end:
From 293700.702, 35 occurrences related to city Moscow
From 293703.004, 33 occurrences related to city Ngapuhi
Both cases coincide with a flush and rebuild of the "building value cache"
Then at the end of the file, 3 occurrences, with no city or cache rebuilding "context". As the last entries on the flight recorder, and uniquely (for this file anyway) occurring without reference to a city, are you sure these don't help you out with the cause of the crash?
For example, if it subsequently finds a valid unit to build, but then finds it's been evaluating options for an invalid or nonexistent city.
The link is not to a public page, I don't have the necessary civfanatics permission to view the content of the page the link goes to.
I have the same problem as Toffer. You don't seem to have attached the attachment to the post. You probably need to do that.
I don't know how you got an attachment number without an attachment, did you attach it and then remove it again?
Separate names with a comma.