Jump to content

Game crashes on startup


LukeV1
 Share

Recommended Posts

I've got it - at least I think so. This was the last time the breakpoint was hit before the buffer overflow exeption popped up. The file is "template_unit_hero.xml" (see screenshot).

I figured that out manually by making a screenshot and clicking countinue each time CXeromyces::Load was called which seemed to happen a million times. So I was wondering if I could insert a simple

 std::cout << *filename

in CXeromyces::Load to print all called files to the console? This would be a lot faster since I would know the last file printed was the broken one. Is that possible?

As I said I'm new to such large scale projects but I've attended a C/C++ course at university, so I know at least a few basics..

Thatsitprobably.png

Link to comment
Share on other sites

Unfortunately template_unit_hero.xml is a false positive. I've inserted a LOGMESSAGE output and pyrogenesis.exe crashes at a different xml file each time. (BTW: the absolute path to template_unit_hero.xml  is 107 chars long, there are no spaces oder special characters).

So I guess it isn't related to any special file but to some problem with memory management :wacko: I have no clue what to do next...

Link to comment
Share on other sites

21 hours ago, elexis said:

If I read correctly, the complain in the callstack is not reading the file but writing the converted file (must be the cache).

Writing the cache files is the problem. When I'm deleting the cache the game crashes right on startup (while loading the menu) a couple of times - but then it got everything cached and at least the menu works. What I figured out so far that the crash isn't caused by any specific file. It seems as if it crashes after a certain numer of written bytes...

I've checked the cache folder, no special permissions set (0 a. D. is capable of writing a few files there but then suddenly crashes..)

Link to comment
Share on other sites

20 hours ago, stanislas69 said:

Disk Space ? Running 0ad as admin ? Disk state (run check disk) ?

Disk Space: around 300 GB free, running as Admin didn't change everything, chkdsk found nothing to complain about on any drive.

This problem is getting worse with every step we make to find it :o

Link to comment
Share on other sites

Now I've got the extact line where the program crashes: it is

vfs->CreateFile(xmbPath, writeBuffer.Data(), writeBuffer.Size());

in the function CXeromyces::ConvertFile of CXeromyces.cpp

Is there any realistic chance that these parameters are faulty (e. g. overflow?) or the function is doing something wrong in a special case?

Link to comment
Share on other sites

I've found debug_printf, which works pretty decent, so no need of cout anymore..

Now I got the line inside CreateFile (part of vfs.cpp) where it crashes:

RETURN_STATUS_IF_ERR(realDirectory->Store(name, fileContents, size));

I've already checked that size is > 0 and name isn't empty. Both got believable values at the error. Have no clue how to check fileContents, though.

Could the crash output (wsysdep.cpp(358): Assertion failed: "charsWritten < max_chars") mean that size was too big for some reason?

Link to comment
Share on other sites

  • 2 weeks later...

I'm finally coming back to the subject after having a few days off :P

Now I've checked that size got a valid size (>> 0), pathname got a (seemingly) valid name and that the fileContents Pointer actually points to something. At the crash all values seemed normal (comparing to all other converted files before)...

What can I do next - or where should I probably take a look at?

Edited by LukeV1
Link to comment
Share on other sites

45 minutes ago, elexis said:

Are directory permission issues actually ruled out?

I think so. I'm running 0 A.D. on a single-account windows with standard admin privileges - starting pyrogenesis by choosing "running as Admin" explicitely doesn't change anything. No special rights set for any appdata folder.

As mentoned somwhere above, 0 A. D. is able to save a few files to this directory before crashing - so I guess it hasn't to do anything with directory permissions (otherwise it shouldn't be able to write a file at all, right?).

Link to comment
Share on other sites

Important Update:

I figured out the problem: the installed antivirus scanner (G DATA Internet security) seems to block all file accesses made by pyrogenesis after a few dozen file changes in appdata subdirectories. So elexis is right - it actually is a directory permission issue - but not caused by windows :blink:

When I deactivate all virus scanner services the SVN version works. Though, I'm not sure why this happens since I use exactly the same antivirus software on a few other PCs (win7 / win8.1) where the SVN version works... Seems to be a windows 10 specific "feature".

Since I'm the only one affected by this I will close the ticket on track and handle the problem as solved.

 

Thanks to everybody who helped me on this! :)

  • Like 2
Link to comment
Share on other sites

  • 3 months later...

@LukeV1 Are you still around? I believe we should fix this issue for the upcoming release, otherwise many people will report the same crash that is hard to figure out initially.

Since you already wrote code around that bug, would you honor us with a patch that just shows a human readable message instead of a crash / debug breakpoint? :-)

  • Like 1
Link to comment
Share on other sites

Im still around :)

Actually I didn't wrote any code around the core issue. As written here, I had two problems. The first one (HWDetect) is easily solvable but that's not what you meant (it already displays an (ignorable) error message). The other one - the bad one - wasn't solved through coding, but by adding an exception path to the antivirus scanner.

 

I might ask the G DATA Software AG for investigation, if you would like that?

Edited by LukeV1
removed unecessary stuff
Link to comment
Share on other sites

SVN wasn't working cause I had a local compiler issue :rolleyes:

I tackled down the problematic code even further, it has to do with the function "wtruncate" in "wfilesystem.cpp". Will take a look at that soon - at the moment it seems as if this returns a Null pointer or crashes internally, when the antivirus software is getting angry...

Link to comment
Share on other sites

After some testing I found out that saving a file isn't the problem - the last file processed before crashing gets written and closed correctly (all of this happens in io.h).

The issue is the afterwards called "wtruncate"-function (an API-call) whichs crashes without producing an error message or return value. Try and catch that line doesn't work.

 

Unfortunately I don't know how I can prevent/print errors from an API-call...

BTW: Is there any function like

ENSURE(pathname.has_write_permission)

?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...