Boost.Log rotation may throw boost::filesystem::filesystem_error about log HOT 10 CLOSED

@Lastique How about specifying m_TargetStorageDir as m_StorageDir, when m_TargetStorageDir is empty?

from log.

I don't like introducing this kind of non-obvious behavior.

When I wrote the following codes, I would naturally assume that target_file_name would be in the same directory as file_name. New log file is temporarily create in m_TargetStorageDir, and will be move to m_StorageDir. So I think this behavior do some good.

keywords::file_name = log_file,
keywords::target_file_name = config.stem + L"_%Y%m%d_%H%M%S_%5N.log"

from log.

As any filesystem operation, rotating log files may fail, this is to be expected. From your information, it isn't clear what exactly happened, so I can't tell whether the error is legitimate.

In any case, in order to handle exceptions, you can set an exception handler to the sink frontend.

from log.

@Lastique I already set exception handler, still can NOT catch the exception.

struct ExceptionHandler {
    typedef void result_type;

    void operator()(std::exception const& e) const noexcept {
        OutputDebugStringA(std::format("std::runtime_error: {}\n", e.what()).data());
    }
    void operator()(boost::filesystem::filesystem_error const& e) const noexcept {
        OutputDebugStringA(
            std::format("boost::filesystem::filesystem_error: {}\n", e.what()).data());
    }
};

// catch nothing
auto core = logging::core::get();
core->set_exception_handler(
    boost::log::make_exception_handler<std::exception, boost::filesystem::filesystem_error>(
        ExceptionHandler()));

// catch nothing
file_sink->set_exception_handler(
    boost::log::make_exception_handler<std::exception, boost::filesystem::filesystem_error>(
        ExceptionHandler()));

from log.

If it doesn't catch then the exception is not one of the types you listed. BTW, it doesn't make sense to list std::exception first, because it will be caught before filesystem_error by the handler function object. Exceptions should be listed from the most specific ones to the most general ones, similar to how you order them in the catch blocks.

Also note that std::format is not noexcept.

Getting back to the problem, you should debug to see what the exception type is and where it is being thrown.

from log.

Thank you! I'll improve my codes.

From minidump, I see the exception is a boost::filesystem::filesystem_error. Since the crash is on other users' machine, I can't debug.

from log.

For the record, the basic_formatting_sink_frontend::feed_record function is here:

As you can see, the function does catch all exceptions thrown by backend.consume(), so the fact that the exception keeps propagating after that means that the exception handler is not set or that it has rethrown the exception. Or that the exception fails to be caught in the first place, but then this sounds like an ABI issue (e.g. when multiple different versions of filesystem_error exist in the process, or the language runtime fails to catch the exception for some other unknown reason).

from log.

I think I've solved this issue by adding directory to target_file_name.

 keywords::target_file_name =
                    config.directory / (config.stem + L"_%Y%m%d_%H%M%S_%5N.log")

If the directory is not specified, the new log file will be created on %ProgramFiles%\<Company>\<ProductName>, which is readonly. See the following code, m_pImpl->m_TargetStorageDir is null. filesystem::create_directories(new_file_name.parent_path()); will throw.

//! The method rotates the file
BOOST_LOG_API void text_file_backend::rotate_file()
{
    filesystem::path prev_file_name = m_pImpl->m_FileName;
    close_file();

    // Check if the file has been created in the first place
    system::error_code ec;
    filesystem::file_status status = filesystem::status(prev_file_name, ec);
    if (status.type() == filesystem::regular_file)
    {
        if (!!m_pImpl->m_TargetFileNameGenerator)
        {
            filesystem::path new_file_name = m_pImpl->m_TargetStorageDir / m_pImpl->m_TargetFileNameGenerator(m_pImpl->m_FileCounter);

            if (new_file_name != prev_file_name)
            {
                filesystem::create_directories(new_file_name.parent_path());
                move_file(prev_file_name, new_file_name);

                prev_file_name.swap(new_file_name);
            }
        }

        if (!!m_pImpl->m_pFileCollector)
            m_pImpl->m_pFileCollector->store_file(prev_file_name);
    }
}

from log.

I think I've solved this issue by adding directory to target_file_name.

Good, it explains why you were getting an exception. It doesn't explain why the exception wasn't caught, though. Which means, if an exception is thrown for whatever other reason, you will have the same problem again. I'd recommend continuing debugging to fix this. Double-check that you set an exception handler for all sinks. Check if it's actually being called by setting a custom function object with console output or something instead of the one generated by make_exception_handler.

from log.

@Lastique How about specifying m_TargetStorageDir as m_StorageDir, when m_TargetStorageDir is empty?

I don't like introducing this kind of non-obvious behavior. Currently, any relative paths you provide to the library are interpreted the same way as anywhere else in the process - they are relative to the current path for the process. Which means, it is probably a good idea to always provide absolute paths. But that doesn't mean it is a good idea to replace the path behind user's back.

from log.