Mysterious empty files



  • A mystery. Need ideas, or even a name for this problem.

    It sounds to me like we're using up some resouce that's not being cleaned up, but what?

    We have a Java listener that spawns a Java-calling-C++ application created with the Complicator's Gloves...

    The interior C++ routine loops: reads one of a series of 10 files, does stuff, writes a file.
    So when you're done, you should have 10 input files, and 10 corresponding output files.

    The problem:
    After restarting the listener, the application reads and writes all 10 files. The next time the application is spawned and run, it creates but does not write all 10. It leaves empty a few at the end of the series.  The next time, it leaves more of the series empty. Eventually, all 10 of the output files will be created, but will be empty.

    This application works fine in Dev and Test, fails in Production. Environment is W2008 under VM.

    WTF!!?? 

     

     



  • Okay, I'm going to go with the really, stupidly, blindingly obvious: are the output streams being explicitly flushed/closed? Other than that, I got nothing.



  • 1) Make sure the folder is not "optimized" for something. This can cause weird behaviors (see: here)
    2) Did you try Process Explorer? At least it will tell you if that's your application that locks the files or something else.



  • @mikeTheLiar said:

    Okay, I'm going to go with the really, stupidly, blindingly obvious: are the output streams being explicitly flushed/closed? Other than that, I got nothing.
     

    Yea!  An answer... thought I had been pigeon-holed for  "asking for teh codz." maybe.

     Source code says they're being flushed and closed immediately after use...

    (but I have a small bet with myself that he's overloaded the methods somewhere and
    wrote his own file-caching "for performance reasons")



  • @Ronald said:

    1) Make sure the folder is not "optimized" for something. This can cause weird behaviors (see: here)
    2) Did you try Process Explorer? At least it will tell you if that's your application that locks the files or something else.

    Also - "yea an answer"!   I'll look at those thanks!  Update - I managed to break it in Test as well, so at least (most?) configuration issues are off the table.



  • The fact that less and less files get populated each time the application is run makes me think that there might be a looping issue somewhere. An iterator with [b]i-1[/b] instead of [b]i[/b] or something.




  • I would double-check the error handling code.

    • Are all errors logged? Don't forget to capture stdout/stderr of the child processes.
    • Are all return values checked and no exceptions swallowed? Note that C++ iostreams don't throw by default.
    • Are all input files actually non-empty? There could be a race condition if the application is launched too early (before all input files have been written).


  • BoC:   the  read-input-file and write-output-file code are inside the same simple loop. Thanks for thinking about it, tho.

     Fatbull: Thanks.

     There's logging for "everything"** going to several different logs - in the code we have log files and logging objects - they are helpfully named things like: the_log, and logger.

    Good to know that about C++  iostreams...

    Re: the race condition: I'm suspecting something like that...

    So, I'm futzing with Process Explorer as suggested.... (also migrating my desktop with deadline of today)

    ** "everything" = a lot <> Everything  YMMV. Well, MyMMV...

     

     


Log in to reply