Jump to content

janwas

WFG Retired
  • Posts

    2.733
  • Joined

  • Last visited

Posts posted by janwas

  1. Surely we can just tell it? We know that most low-level errors are always bad and should be reported in ugly dialog boxes. We also know that if config/default.cfg doesn't exist then it's a serious error and should be reported seriously

    hehe, it's not quite that simple. Sure, we can check if the error is "file not found".

    However, what was happening in this case is "dir not found" (files and directories are tracked separately). I think the capability of differentiating them is potentially useful, but it'd be burdensome if user code had to check for both of them. (Worse yet, delayed population of directories can postpone file enumeration errors - e.g. due to antivirus - until the first file lookup.)

    If GetFileInfo will always either return FILE_NOT_FOUND or raise an ugly dialog box itself, then that's okay, but I don't want it to silently ignore any other errors; and it looks like GetFileInfo doesn't do that, and the new code looks like it will silently ignore the other errors.

    GetFileInfo only avoids an *additional* error dialog from CHECK_ERR if you "pass in a flag" (i.e. set pfileInfo to 0), independent of the actual error. However, the new code doesn't silently ignore other errors because they are still reported when first returned from a function.

    That Boost behaviour sounds like a bit of a pain, and I don't see any way around it. (umask could work but it's seemingly not thread-safe so it's probably too dangerous.)

    *nod* I've implemented our own CreateDirectories with a mode_t parameter.

    Write a test which creates an empty directory, sets $HOME to it, then runs InitVfs (suitably refactored to be testable) and writes some files and then checks the test directory contains all the right files in the right locations with the right permissions? (and then repeat for the other cmdline-dependent mode, and then ideally test edge cases and error handling)

    Sounds good ;)

    Have noted this in the never-ending todo list.

  2. http://trac.wildfiregames.com/changeset/7065#file6 -- the intent was that any errors other than file-not-found would be ignored here, and reported normally when trying to open the file normally a few lines later. With the new change, if e.g. your disk accidentally turned into cheese then you'll get a "Cannot find config file" warning instead of the proper disk-is-made-of-cheese error, which would be confusing. So either it should ignore all errors except the legitimate file-not-found/container-directory-not-found/etc ones (so it'll try to open the file and complain about any persistent errors), or else the warning text should be changed.

    Ah, that's a good point, but it looks like philosophical territory. The original intent was that all (low-level) errors be reported immediately when they are generated (i.e. by using WARN_RETURN ERR::xxx instead of return ERR::xxx), so the cheese error (hehe) wouldn't be ignored.

    Also, there is something to be said for the main game code saying "cannot find config file" regardless of whether it's just because the file wasn't found or because the disk is made of cheese - the result is the same.

    Finally, how can the game code (or for that matter, LoadFile) know what errors to ignore and which ones should actually reported? I'm pretty happy so far with the policy of reporting everything unless a particular error happens often/legitimately, but am happy to be convinced otherwise.

    The tests fail:

    Uhoh :) Unfortunately I'm out of time today and probably won't be able to look into the issue until the weekend due to an upcoming trip.

    Directories aren't created with 0700 permissions (which XDG basedir requires) - they seem to be 0755.

    Yep, I couldn't see a way to do so with the boost filesystem API - create_directory lacks a mode_t parameter:

    Attempts to create the directory dp resolves to, as if by POSIX mkdir() with a second argument of S_IRWXU|S_IRWXG|S_IRWXO.

    We should revert to calling mkdir then, eh?

    There's no tests for the new code, so it would be easy to break it in the future and start putting files in the wrong locations and not notice.

    Yeah, I'm kind of worried about confusion regarding profiles etc., especially because the old location is still supported (depending on cmdline args). Do you have any ideas?

  3. Interesting, I've not seen such an error before.

    Are you running on a least-permissions account or as admin? Vista, XP or Win7? 64-bit?

    Not sure if it has anything to do with WMI service within windows xp.

    Yep, we use WMI to retrieve certain system information. Until the problem is found and fixed, you can launch with the -quickstart command line argument (which disables the system detection code and sound).

    A bit above me as to what it even does other then warn me about error # 4.

    The error#4 bit is just so we can see exactly which function failed. If you have access to a debugger, could you please post the value of hr? (If not, the error code should be visible in the Application section of the Windows EventLog)

    A web search shows several similar problems.

    If you start->run compmgmt.msc -> services and applications -> wmi control -> right-click -> properties, do you see an error?

    http://www.pcreview.co.uk/forums/thread-526766.php was solved by ensuring %windir%/system32/wbem is on the path.

    You may also want to check out the wmidiag tool (it seems to be useful for such problems).

  4. Yep, looks like the space is causing problems. (I'm not sure how hard it'd be to change our build system to cope with those spaces - someone should feel free to look into it )

    Yep, that's the cause (cxxtestgen is the culprit). The build instructions call for checking out into a directory without spaces; it would be slightly nicer (in a low-priority sense) to rule out this cause of errors, but I have no idea how much trouble that would entail.

    The crash issue seems to be a problem with the environment on my machine, it has since stopped and I cannot reproduce it.

    hm, that's strange (and slightly worrisome to have unknown bugs lurking nearby). One thing that changes with time is the translation of XML files to XMB. I guess it's possible for one of them to have been garbled, and the recent change from binaries/cache to $appdata/0ad/cache may have hidden the issue. Would you like to try deleting the former and renaming the latter cache folder?

  5. Assertion failure: (uint32)2 < JS_MIN(((obj)->map)->freeslot, ((obj)->map)->nslots), at jsapi.c:2118

    Aborted

    Hm, this might be another instance of a known problem when the SpiderMonkey library wasn't compiled with the same version/flags we need. Mid-term, Philip (who knows more about the topic) was wanting to add source+makefiles to SVN so that we can rule out such incompatibilities. Unfortunately I don't know a short-term workaround, nor can I help with the wxW issue.

  6. Hi Brandon and thanks for reporting the problem!

    Those files are all generated by the test_gen project and do not exist in the non-public repository, either.

    Could it be that test_gen isn't being built, or that dependencies are incorrect? (test_gen needs to build before test)

    About the game crash problem: whether unrelated or not, we'd be happy to try and solve it. Please feel free to create a trac ticket (CCing "jan" ensures I'll see it faster) or attach binaries/logs/crashdump.* here.

  7. Ah, that is helpful! The crash is apparently inside the error reporting code, which is why you aren't seeing the "Program Error" dialog. However, the crashlog.dmp file in binaries/logs/ should have been written by that time and is essential to finding out what happened. Can you please post that as well as pyrogenesis.exe and pyrogenesis.pdb?

  8. I'm fine with using XDG, it's reasonably straightforward.

    Subdirectory 0ad - makes sense.

    mkdir with 0700 - done.

    Alternative: Maybe we could skip the mods/*/*.zip thing, by not dynamically creating archives - just do it once during system-wide installation, and never at runtime.

    I'm fine with that. This archiving code has long been dormant anyway.

    For efficiency, /usr/share/games/0ad/data/cache/ should be initialised (on installation) with conversions of all the .xml and .dae files.

    How would that work? Do we really want to create a separate cache-everything routine or executable?

    BTW, the VFS was designed for this kind of thing, but the underlying path.cpp's Path presumes that everything will reside in one directory. Am currently removing that logic.

  9. The error says: " Pyrogenesis .exe". You have an error with pyrogenesis exe. The application will be closed. Maybe you have lost your data

    Interesting. I would've thought that to be "impossible" because we have a crash handler that should intercept any errors (and report information about them) before the normal Windows dialog comes up.

    Do you see anything in the Windows event viewer, or when running DbgView while attempting to start the game, or any files created in binaries/logs/?

    Well, I apologize, I realize now an installer is probably not a good thing for developper's health at the moment

    Don't blame me

    heh, no worries. Let's just keep in mind that the probability of fixing an error is directly proportional to the amount of information provided. Frankly, with the above four reports, that chance is near zero.

    An analogy for non-software-developers: imagine you build an oil rig and someone tells you: "it exploded". Is that enough information to understand the cause?

  10. (I'm beginning to feel like a broken record..)

    What is the exact error message? Is it shown by Windows in your native language or by an english-language dialog entitled "Program Error"?

    To give us a realistic chance of diagnosing the error, can you post binaries/logs/crashdump.*?

  11. What's the error message? Can you post binaries/logs/crashdump.*?

    I don't think it makes a difference on which machine you compile, except for maybe the compilers' runtime libraries already being installed. However, we account for that issue (they should all be distributed in SVN).

  12. Location: wdll_ver.cpp:57 (ReadVersionString)

    Looks like the same error as above. Are you running Vista? 64-bit or 32?

    This message is just a warning, and until it's fixed (which requires more information for purposes of debugging) you can either just ignore it (choose continue or suppress) or start the game with -quickstart (which disables the system-detection code that calls ReadVersionString as well as sound).

    Performance warning: your graphics card does not support compressed textures.

    This one's probably a show-stopper. The game isn't going to run well without a GeForce III-level GPU, and current onboard offerings aren't there yet. Is upgrading your GPU an option? :)

    Some prerequisites to run the game (like directx version or so)? It crashes also to me when i launch it after installing.

    Are those the only errors that show up? We can't debug crashes without more information, most importantly the files crashdump.txt and crashdump.dmp.

  13. Thanks Jeru, but I rather won't because this error occurs when I use the installer, which is irrelevant to the developers.

    Don't get me wrong, we are happy to look at the issue, it's almost certainly not caused by the installer itself. (The wdll_ver issue is likely caused by Windows' automatic path redirection. Are you running a 64-bit version of Vista?)

    As Jeru says, though, we need the crashlogs to get anywhere. Please feel free to CC "jan" if you create a ticket so that I'll see it sooner.

×
×
  • Create New...