#222 rtweight crashes on Windows

crash or data loss
closed-fixed
Analysis (10)
8
2009-07-17
2009-07-16
Wim Bokkers
No

When running rtweight on a geometry, it crashes with the error: rtweight.exe has encountered a problem and needs to close.
There is a .density file located in the home directory AND in the current directory AND in the binaries directory (just to be sure).

Discussion

  • Sean Morrison

    Sean Morrison - 2009-07-16

    This is just a guess, but it could be a problem with line endings in the .density file. Can you make sure your .density file(s) have windows line endings (you can create a simple on by hand in Notepad.exe for example)? If they are, then try the opposite -- make them have unix line endings and see if that changes anything.

    Without a stack trace or more debugging information, it's hard to say what's going on but line ending management is something that has come up before with other file-processing tools.

    Another thing you can do is to add "-X1" to the rtweight options and see if there's any more diagnostically useful information shown.

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-16

    I tried al sort of line endings. rtweight keeps crashing.
    But it does display the db title and does a succesful dirbuild (it prints som information about the elapsed time)
    The -x1 option does not give me more information. If there is no .density file, the same error appears.
    I tried to get a call stack, but the binary was not build with debug information.

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-16

    What is the exact format of the .density file?

     
  • Sean Morrison

    Sean Morrison - 2009-07-16

    Try with "-! ffffffff" on the command-line. It should spew lots of debugging output. If you provide that as an attachment, hopefully it'll provide some insight at least into where it's halting.

    There is an example .density file here that is known to work: http://brlcad.org/tmp/.density

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17

    Geometry file

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17

    Used .density file

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17

    Debugging output

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17

    I tried with the .density file you supplied (I could not save the file from IE, since is was displayed in the browser: I copied te text into notepad and then saved to .density)

    See attached files for used input and debugging output.

     
  • Sean Morrison

    Sean Morrison - 2009-07-17

    That was useful. It appears to be halting during view_init() which is basically where the .density file is parsed. At least that's where the debugging stops. Hopefully it's not buffered output or that'll mean it could be during tracing as well.

    In searching for a .density file, rtweight is going to search first in the current directory, then in your home directory, using the first one it finds. It locates those places by looking at the PWD and HOME environment variables respectively (can run "echo $PWD" and "echo $HOME" so see their values). Try removing the .density from both places and make sure you get an "Unable to load density file" error.

    If you can get that error, then you can try creating a one-line .density file in your current directory. Format is:
    INT[space]FLOAT[space]STRING

    So something as simple as:
    0 1.0 WATER
    should work depending on the newline situation. Try both unix line endings and windows line endings.

     
  • Sean Morrison

    Sean Morrison - 2009-07-17

    On second thought, it would probably be best to start with index 1 in your .density file. There was a problem back in 7.8 days with index zero. Try something like "1 1.0 WATER" instead. Even an empty file should work (or at least is worth testing).

     
  • Sean Morrison

    Sean Morrison - 2009-07-17
    • assigned_to: nobody --> brlcad
    • status: open --> pending
     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17

    Thank you.
    I found the problem.
    On Windows, the PWD and HOME environment variables are not defined.
    If I define them, everything works as expected.

    This is still a bug, though. rtweight should not crash. ;)

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17
    • status: pending --> open
     
  • Sean Morrison

    Sean Morrison - 2009-07-17

    You make it sound like we wouldn't fixed it.. :) I'm not sure we've ever done that for something that crashes (at least knowingly, have we?). At least not once the problem is actually identified. That's why there's a separate category for crash over bugs that may or may not have a workaround on this tracker. None of the tools should *ever* crash regardless of inputs or environment. This one was, of course, a case of bad environment assumptions and non-robust testing of results.

    Undoubtedly getenv() is returning NULL and strlen() is crashing. I've added some simple tests that should stop the crashes and will look into a more robust solution in case there are other places in the code where this pattern occurs.

    Thanks Wim!

     
  • Sean Morrison

    Sean Morrison - 2009-07-17
    • status: open --> closed-fixed
     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17

    I'm sorry to have mentioned the obvious (fixing a bug causing a crash).
    I can't remember a situation in wich a crash was not fixed.... maybe I'm just short of memory ;)

    Thank you for the very quick responses!
    Now I can enjoy my vacation..

     
  • Wim Bokkers

    Wim Bokkers - 2009-07-17
    • status: closed-fixed --> open
     
  • Sean Morrison

    Sean Morrison - 2009-07-17
    • status: open --> closed-fixed
     
  • Sean Morrison

    Sean Morrison - 2009-07-17

    Heh, no need to apologize. Thanks again for the report!

    Fixed as of r35163, closing item.

     

Log in to post a comment.