Boost.Log crash - question on consequences of misconfiguration
LS, My question regarding Boost.Log is the following: could anything been said on what to expect when asking Boost.Log to write to a non-existing directory on a read-only drive? Does it keep trying to write or give up when the directory cannot be created, and would the user be informed in such a case? Background: today I ran into a problem using Boost.Log. I configured both a Console and a TextFile backend (both autoflushing) but happened to configure the latter wrongly- setting the location of the file on a not-existing directory on a read-only drive. This caused a program crash under certain circumstances - but no problems under other circumstances (related to the configuration of the application which should not be relevant here) - when it did crash, this happened after a few messages were logged. Crash happened shortly before program termination but before the main() function was terminated (for a while I thought I was seeing the problem described in the docs regarding the boost.filesystem related problem and it took me a while to learn this was not the case). Pieter
On Tuesday 11 February 2014 20:15:35 Pieter wrote:
My question regarding Boost.Log is the following: could anything been said on what to expect when asking Boost.Log to write to a non-existing directory on a read-only drive? Does it keep trying to write or give up when the directory cannot be created, and would the user be informed in such a case?
The expected behavior is that Boost.Log tries to create the directories and the file on the first logged record but fails with an exception (during boost::filesystem::create_directories() call). If the exception is suppressed, this would happen on every logged log record.
Background: today I ran into a problem using Boost.Log. I configured both a Console and a TextFile backend (both autoflushing) but happened to configure the latter wrongly- setting the location of the file on a not-existing directory on a read-only drive. This caused a program crash under certain circumstances - but no problems under other circumstances (related to the configuration of the application which should not be relevant here) - when it did crash, this happened after a few messages were logged. Crash happened shortly before program termination but before the main() function was terminated (for a while I thought I was seeing the problem described in the docs regarding the boost.filesystem related problem and it took me a while to learn this was not the case).
It's hard to diagnose the problem not having a backtrace or a code sample, but my initial guess is that it was probably not a crash but the application terminated due to an uncaught exception.
participants (2)
-
Andrey Semashev
-
Pieter