Bugs in ARGoS cmdline about argos3 HOT 8 CLOSED

I tried the following commands on my machine, and they work as intended:

argos3 -l /dev/null -c experiments/diffusion_1.argos
argos3 --log-file /dev/null -c experiments/diffusion_1.argos

from argos3.

Found the issue! The specific use case I was targeting was when I get the library name wrong for either the controller or the loop functions, and ARGoS doesn't start. In those cases, I still want ARGoS to only return non-zero, and not print anything to the screen. However, when the library name is wrong ARGoS will throw an uncaught exception. If I do :

LOG << "some text" << std::endl

Anywhere before or after the library fails to load and things ultimately crash, it is silent. However, if I do:

LOGERR << "some text" << std::endl

Then I still see the text when the exception prints. I imagine its being buffered (and not yet set to /dev/null), and when the exception prints that mechanism takes anything that was queued up for stderr and prints it to the terminal. I don't see the text if I call Flush() before the exception triggers.

I think the easy part of the solution here is to update the man page so that it's clear users can't do --log-file=/some-file on --logerr-file=/other/file (it currently says they can). For the other part, I think its reasonable as a user to assume that if you set the stderr logfile to something via --logerr-file that everything that would come out on stderr should go to it, including exceptions. I'm not really sure how to implement this though. If this can't be implemented/would require too many changes, then the man page should be updated to say that ARGoS will still print exceptions on startup even when --logerr-file is passed.

from argos3.

Are you using a custom main.cpp file?

In the original main.cpp the log redirection is set before the libraries are loaded (see here), so the errors, in theory, should be redirected to /dev/null.

from argos3.

Yes, I'm currently using the latest ARGoS master. I also tried with a normal file (/tmp/foo.txt), and saw the same result, so it's not an issue with redirecting to a special system file. I'm on ubuntu 20.04, if that makes a difference.

from argos3.

Maybe we can add a Flush(), as you suggested, just after the command line arguments are parsed. Can you try adding the following code:

#ifdef ARGOS_THREADSAFE_LOG
      LOG.Flush();
      LOGERR.Flush();
#endif

at the end of this method?

from argos3.

That didn't change anything, but it got me to the answer. LOG and LOGERR wrap std::cout and std::cerr, which are different than stdout and stderr (the C file descriptors). When exceptions are printed, they apparently get printed to stderr, not to std::cerr.

Adding the following to argos_command_line_arg_parser.cpp:113 right after the redirection for std::cerr works:

freopen(m_strLogErrFileName.c_str(), "w", stderr);

similarly for stdout. With these and no other changes, ARGoS is indeed silent when the redirection options are passed.

from argos3.

Great! Thanks for looking into this. Feel free to make a pull request for this fix when you have the time.

from argos3.

Opened #209, closing this.

from argos3.