Stan` Posted September 11, 2017 Report Share Posted September 11, 2017 @LukeV1 Can you try to figure out which file is being loaded when that crashes ? Putting a breakpoint in CXeromyces::Load should help locating it. 1 Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 11, 2017 Author Report Share Posted September 11, 2017 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.. Quote Link to comment Share on other sites More sharing options...
Stan` Posted September 11, 2017 Report Share Posted September 11, 2017 Yeah that could work or you could use the LOGMESSAGE function. Maybe something is wrong with that file. Does the path to that file is big or has special chars ? Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 12, 2017 Author Report Share Posted September 12, 2017 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 I have no clue what to do next... Quote Link to comment Share on other sites More sharing options...
elexis Posted September 12, 2017 Report Share Posted September 12, 2017 If I read correctly, the complain in the callstack is not reading the file but writing the converted file (must be the cache). So check for write permissions to the cache folder, see wiki/GameDataPaths. Note the released bundle doesn't use the cache directory as all files were pre-converted (or were that only textures?) 1 1 Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 13, 2017 Author Report Share Posted September 13, 2017 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..) Quote Link to comment Share on other sites More sharing options...
Stan` Posted September 13, 2017 Report Share Posted September 13, 2017 @LukeV1 Disk Space ? Running 0ad as admin ? Disk state (run check disk) ? Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 14, 2017 Author Report Share Posted September 14, 2017 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 Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 14, 2017 Author Report Share Posted September 14, 2017 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? Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 14, 2017 Author Report Share Posted September 14, 2017 @stanislas69 where can I watch the output of std::cout ? I wanted to insert a few debug texts in the ("lowlevel") file vfs.cpp where I can't use LOGMESSAGE but I don't find the messages printed by cout... Quote Link to comment Share on other sites More sharing options...
Stan` Posted September 14, 2017 Report Share Posted September 14, 2017 I'd look at the bottom view of visual studio, there are different kind of outputs, so should appear there. We are going to figure this out. Thanks for your time an patience so far. 1 Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 15, 2017 Author Report Share Posted September 15, 2017 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? Quote Link to comment Share on other sites More sharing options...
Stan` Posted September 15, 2017 Report Share Posted September 15, 2017 Well Could be. Can you try to print the values of those two variables ? Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 16, 2017 Author Report Share Posted September 16, 2017 12 hours ago, stanislas69 said: Can you try to print the values of those two variables ? Already did that. But since it crashes always on a different file it's hard to tell how big size should be.. I'll append a Screenshot from a random debug run. Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted September 25, 2017 Author Report Share Posted September 25, 2017 (edited) I'm finally coming back to the subject after having a few days off 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 September 26, 2017 by LukeV1 Quote Link to comment Share on other sites More sharing options...
Stan` Posted September 25, 2017 Report Share Posted September 25, 2017 I'm not sure. Maybe @leper or @Itms have more insight. Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted October 1, 2017 Author Report Share Posted October 1, 2017 opened a ticket on trac: https://trac.wildfiregames.com/ticket/4802 Quote Link to comment Share on other sites More sharing options...
elexis Posted October 1, 2017 Report Share Posted October 1, 2017 Are directory permission issues actually ruled out? 1 Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted October 1, 2017 Author Report Share Posted October 1, 2017 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?). Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted October 1, 2017 Author Report Share Posted October 1, 2017 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 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! 2 Quote Link to comment Share on other sites More sharing options...
elexis Posted October 1, 2017 Report Share Posted October 1, 2017 Those things are hard to guess. I'm glad you figured it out and we devs can recall that ext time someone runs into file permission issues. 1 Quote Link to comment Share on other sites More sharing options...
elexis Posted January 27, 2018 Report Share Posted January 27, 2018 @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? :-) 1 Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted January 27, 2018 Author Report Share Posted January 27, 2018 (edited) 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 January 29, 2018 by LukeV1 removed unecessary stuff Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted January 28, 2018 Author Report Share Posted January 28, 2018 SVN wasn't working cause I had a local compiler issue 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... Quote Link to comment Share on other sites More sharing options...
LukeV1 Posted January 29, 2018 Author Report Share Posted January 29, 2018 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) ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.