After the third execution of the application the boost log figures out, that the directory size of 200 bytes has been exceeded and it it's necessary to delete the oldest logfile, afterwards it crashes.
I appreciate your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-03
Hi.
Please find the stack trace below:
Thread 0 (Suspended : Signal : SIGSEGV:Segmentation fault)
0x44727c
boost::filesystem::path_traits::convert() at 0x44757f
_fu1363___ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE() at 0x447883
boost::filesystem::detail::status() at 0x4488da
_fu1169___ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE() at 0x437bb7
boost::log::v2s_mt_nt5::sinks::text_file_backend::rotate_file() at 0x436bc6
0x3852d4
boost::log::v2s_mt_nt5::sinks::synchronous_sink<boost::log::v2s_mt_nt5::sinks::text_file_backend>::~synchronous_sink() at 0x48934c
boost::detail::sp_ms_deleter<boost::log::v2s_mt_nt5::sinks::synchronous_sink<boost::log::v2s_mt_nt5::sinks::text_file_backend> >::destroy() at 0x4035e6
boost::detail::sp_counted_impl_p<boost::log::v2s_mt_nt5::core>::dispose() at 0x4a558f
__tcf_0() at 0x42bb97
msvcrt!isspace() at 0x767dc3e9
msvcrt!_cexit() at 0x767e37df
0x0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is in Boost.Filesystem. When the application terminates, Boost.Log attempts to rotate the log file and calls Boost.Filesystem routines, which fail because they use a global locale, which is already destroyed at that point.
The simplest solution for you is to manually remove all sinks before you exit main. This way file rotation will succeed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-03
…okay, but in case I don't terminate my application and keep continuing the creation of log records, the application crashes too, in case the directory size has been exceeded. So either I didn't get your solution or this solution is not the correct one…
You can test this behavior by appending some addintional log records calls to the uploaded code….
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The backtrace you presented indicates program termination. If you have crashes during the active execution, please, provide a backtrace from that kind of crash.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thread 0 (Suspended : Signal : SIGSEGV:Segmentation fault)
0x447e80
boost::filesystem::path_traits::convert() at 0x448183
_fu1363___ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE() at 0x448487
boost::filesystem::detail::status() at 0x4494de
_fu1169___ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE() at 0x4387bb
boost::log::v2s_mt_nt5::sinks::text_file_backend::rotate_file() at 0x4377ca
0xc452cc
boost::log::v2s_mt_nt5::sinks::synchronous_sink<boost::log::v2s_mt_nt5::sinks::text_file_backend>::~synchronous_sink() at 0x489f4c
boost::detail::sp_ms_deleter<boost::log::v2s_mt_nt5::sinks::synchronous_sink<boost::log::v2s_mt_nt5::sinks::text_file_backend> >::destroy() at 0x4041ea
boost::detail::sp_counted_impl_p<boost::log::v2s_mt_nt5::core>::dispose() at 0x4a618f
__tcf_0() at 0x42c79b
msvcrt!isspace() at 0x767dc3e9
msvcrt!_cexit() at 0x767e37df
0x0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's still program termination. Are you not catching an exception by any chance?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-03
I've surrended the complete main application code with a catch block -> Nothing caught…
But you're right: The crash is triggered on terminating the application. I've verified by including a std::cin to stop the application execution.
So, I've to remove the sinks before I leave the applicaiton. I've to check the documenation to figure out how to remove this sinks which were allocated by a "..int_from_settings" call.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-06-03
…but this issue is not nice….
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
from the core while performing application's de-initialization tasks helped me!
As I understood correctly, It isn't necessary to stop feeding and reseting the sinks as long as I'm not using asynchronous logging loggers. If it would be necessary, how can I get the sinks, which were generated by the "settings" schema, from the logging core? There are no "get_sinks…()" methods defined in the core…
But okay, as long as I'm using synchronous logging, its not necessary for me…or?
Thank you for your fast responses Andrey!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, there is no such method currently. This is a known limitation of the API.
As long as you don't use async logging you don't need to stop anything on process termination.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, you can register a formatter factory that will extract a parameter with the timestamp format from the formatter arguments and pass it to the library-provided date/time formatter. Search the forum, I think this was discussed already.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I figured out a crash on Windows XP using the boost.log library.
I'm implementing currently a shared library for Windows. Within this library
I'm using a global logger instance which isn't within a constructor or de-initiated within a destructor. My shared library is linking to the static boost.log library.
My problem occurs: My application, which is using my shared library crashes always on start-up in case logging is enabled:
The logging configuration is read from a configuration file which contains:
[Core]
DisableLogging = false
In case I disable the logging, this means the configuration option "DisableLogging" is set to true, as follows:
[Core]
DisableLogging = true
My application doesn't crash anymore. So it seems, that the "evil" is hosted in the boost.log library.
I've already tried to compile the boost.log library with "BOOST_LOG_NO_COMPILER_TLS" set. But unfortunately, I got the same behavior.
Any ideas?
Regards,
P.S: Within the shared library, which I'm implementing, I'm using a "control"-thread. First I thought, I'm not using any semaphors, to manage the access to the global loger, but actually I figured out, that I'm using a global logger of type "src::severity_channel_logger_mt". So this couldn't be the problem...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ABoostLog WithThread [C/C++ Application]
WithThread.exe [2732]
Thread [2] 0 (Suspended : Signal : SIGSEGV:Segmentation fault)
msvcrt!argc() at 0x77c0330c
msvcrt!crtCompareStringA() at 0x77c2f958
msvcrt!crtCompareStringA() at 0x77c2f79a
msvcrt!crtCompareStringA() at 0x77c2f958
0x3
0xcdf590
msvcrt!__argc() at 0x77c0356a
0x0
Thread [1] 0 (Suspended : Container)
wcsncat() at 0x7c92b3e4
ntdll!RtlpNtMakeTemporaryKey() at 0x7c97d6aa
ntdll!RtlInsertElementGenericTableAvl() at 0x7c959d18
wcsncat() at 0x7c92b298
msvcrt!free() at 0x77bfc3c9
0x3d0000
msvcrt!free() at 0x77bfc3e7
0x54
0x22f62c
msvcrt!malloc() at 0x77bfc42e
setlocale() at 0x77c03c78
0x54
0x0
gdb
More infos:
The crash occurs always in case I use boost.log in an application, which creates a simple thread. within this thread I create some log-records. The main thread also creates some log-records.
This crash just occurs on Windows XP-Platforms. I'Ve tested this on 4 different Windows XP machines. On Windows 7 there is no such crash.
The hpp-file containing the logging code of the application is using can be found here ("Logging.hpp"-file): http://codeviewer.org/view/code:344f
Im currently working 4 days on this crash, but I came not around to solve this problem...
Hope, you can provide me with some useful help. In case nothing helps, our development team has to replace the boost.log library for the production code with another logging library. We hope, this won't be necessary. Our prodcution code has to run on Windows 7 and Windows XP as well Linux-like systems.
Maybe this is a synchronization problem. But we're using the "severity_channel_logger_mt" logger, which should guarentee thread-safety...
Thanks to so far!
Regards
Last edit: RaRi 2013-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me get this straight. You have a dll, which links statically to Boost.Log. No other dlls or the application itself uses Boost.Log in any way (not even includes its headers). Your application links normally with your dll (no /delayload or LoadLibrary stuff). And the application crashes before entering main(). Also, you have RTTI and exceptions enabled when building all dll/exe. Is that all correct?
If so, then I don't see how this could be related to the DisableLogging parameter as the config file is only loaded from inside main(), unless I'm missing something. The only source of problems I can see is some global initialization issue. I can't tell anything more specific without symbol names.
What you can try:
Try linking dynamically with Boost.Log and other Boost libraries.
Try building everything as a monolithic exe and see if anything changes.
Try disabling some functionality to see if it triggers some unexpected code paths. E.g. remove start()/stop() and replace them with a regular logger object.
Try adding more debug output with puts/printf (avoid STL streams for now).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As mentioned in the posts above. I've created a simple test application which links statically to the boost.log libraries (libboost_log_setup-mgw47-mt-1_53.a and libboost_log-mgw47-mt-1_53.a). Within this test executable I include my the boost.log specific logging environment, like stated in this code:
(Logging.cpp: http://codeviewer.org/view/code:344e
"Logging.hpp"-file: http://codeviewer.org/view/code:344f
).
Within the main application I first create a worker thread, which doesn't nothing except to invoke my boost.log-specific logging macro. After the worker thread has been created I also invoke my logging macro within the main. The crash happens...
In case I disable the creation of a worker thread within the main, everything goes fine with the loggging. Not crash, no SIGSEV...
You're right, I use the following configuration file to configure my boost.log-based mechanism. In case I turn the boost-logging in this configuration file off, no crash happens in the multi-thread-version of my test application.
The configuration file is read from within the main function. But please take a look here to understand the test application. http://codeviewer.org/view/code:344c
So please forget currently the DLL stuff. I have created the test application, as I was not sure, if the DLL causes the problems. But actually I figured out, that even in a simple and multi-threaded test application Boost.log seems to produce the crash on Windows XP-bases machines. Maybe the "msvcrt.dll" is not thread-safe...
...what would you suggest to continue with?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please, update the library to the latest version and see if it helps. If it still crashes, a backtrace and a compilable example would be helpful.
Hey!
I've already updated to the latest library version -> Still crash.
Please find the compilable source code here:
http://www.sourcepod.com/hypsmf86-18981
After the third execution of the application the boost log figures out, that the directory size of 200 bytes has been exceeded and it it's necessary to delete the oldest logfile, afterwards it crashes.
I appreciate your help!
Hi.
Please find the stack trace below:
The problem is in Boost.Filesystem. When the application terminates, Boost.Log attempts to rotate the log file and calls Boost.Filesystem routines, which fail because they use a global locale, which is already destroyed at that point.
The simplest solution for you is to manually remove all sinks before you exit main. This way file rotation will succeed.
…okay, but in case I don't terminate my application and keep continuing the creation of log records, the application crashes too, in case the directory size has been exceeded. So either I didn't get your solution or this solution is not the correct one…
You can test this behavior by appending some addintional log records calls to the uploaded code….
The backtrace you presented indicates program termination. If you have crashes during the active execution, please, provide a backtrace from that kind of crash.
…ohh, sorry.
Here is the updated code
http://www.sourcepod.com/zeyexv25-18983
And here the backtrace:
That's still program termination. Are you not catching an exception by any chance?
I've surrended the complete main application code with a catch block -> Nothing caught…
But you're right: The crash is triggered on terminating the application. I've verified by including a std::cin to stop the application execution.
So, I've to remove the sinks before I leave the applicaiton. I've to check the documenation to figure out how to remove this sinks which were allocated by a "..int_from_settings" call.
…but this issue is not nice….
…so, removing the sinks with
from the core while performing application's de-initialization tasks helped me!
As I understood correctly, It isn't necessary to stop feeding and reseting the sinks as long as I'm not using asynchronous logging loggers. If it would be necessary, how can I get the sinks, which were generated by the "settings" schema, from the logging core? There are no "get_sinks…()" methods defined in the core…
But okay, as long as I'm using synchronous logging, its not necessary for me…or?
Thank you for your fast responses Andrey!
Unfortunately, there is no such method currently. This is a known limitation of the API.
As long as you don't use async logging you don't need to stop anything on process termination.
Hi Andrey,
how can I specifiy the format of the timestamp attribute in case the logging options are read via "init_from_stream"?
For example:
I would like to have the following time stamp format : "%d-%m-%Y %H:%M:%S".
Trying it with "%TimeStamp%d-%m-%Y %H:%M:%S" seems not to work.
Okay, one may suggest to configure the time stamp programmatically via the
fileSink->set_formatter (
expr::stream <<
"[" << expr::attr< std::string >("MGPTLTAG") << " - " <<
expr::format_date_time< boost::posix_time::ptime >("TimeStamp", "%d-%m-%Y %H:%M:%S") << "]" <<
" " <<
expr::smessage <<
expr::attr< std::string >("BIER")
But this isn't possible, as I'm not able to retrieve the file sink from the logging core. We have discussed this one or two post earlier...
Question: Is there a possibility to provide a time stamp format string ("%d-%m-%Y %H:%M:%S") to the config file options?
I think, i know your answer: "...register a user-defined format factory...". But the timestamp is a build-in boost.log feature...
Thx so far
Last edit: RaRi 2013-06-04
Yes, you can register a formatter factory that will extract a parameter with the timestamp format from the formatter arguments and pass it to the library-provided date/time formatter. Search the forum, I think this was discussed already.
Hi Andrey,
I figured out a crash on Windows XP using the boost.log library.
I'm implementing currently a shared library for Windows. Within this library
I'm using a global logger instance which isn't within a constructor or de-initiated within a destructor. My shared library is linking to the static boost.log library.
My problem occurs: My application, which is using my shared library crashes always on start-up in case logging is enabled:
The logging configuration is read from a configuration file which contains:
[Core]
DisableLogging = false
In case I disable the logging, this means the configuration option "DisableLogging" is set to true, as follows:
[Core]
DisableLogging = true
My application doesn't crash anymore. So it seems, that the "evil" is hosted in the boost.log library.
I've already tried to compile the boost.log library with "BOOST_LOG_NO_COMPILER_TLS" set. But unfortunately, I got the same behavior.
Any ideas?
Regards,
P.S: Within the shared library, which I'm implementing, I'm using a "control"-thread. First I thought, I'm not using any semaphors, to manage the access to the global loger, but actually I figured out, that I'm using a global logger of type "src::severity_channel_logger_mt". So this couldn't be the problem...
As before, I cannot tell anything before I see the backtrace.
Hi Andrey,
here is the backtrace:
More infos:
The crash occurs always in case I use boost.log in an application, which creates a simple thread. within this thread I create some log-records. The main thread also creates some log-records.
This crash just occurs on Windows XP-Platforms. I'Ve tested this on 4 different Windows XP machines. On Windows 7 there is no such crash.
You can find the source code of the crashin test application here: http://codeviewer.org/view/code:344c
The cpp-file containing the logging code the application is using can be found here ("Logging.cpp"-file):
http://codeviewer.org/view/code:344e
The hpp-file containing the logging code of the application is using can be found here ("Logging.hpp"-file):
http://codeviewer.org/view/code:344f
Im currently working 4 days on this crash, but I came not around to solve this problem...
Hope, you can provide me with some useful help. In case nothing helps, our development team has to replace the boost.log library for the production code with another logging library. We hope, this won't be necessary. Our prodcution code has to run on Windows 7 and Windows XP as well Linux-like systems.
Maybe this is a synchronization problem. But we're using the "severity_channel_logger_mt" logger, which should guarentee thread-safety...
Thanks to so far!
Regards
Last edit: RaRi 2013-06-13
Hi Andrey,
please also consider this backtrace:
Could you rebuild the libraries and the application in debug configuration so that symbol names are visible?
..I've already done this. Unfortunately, I got not more information. But I will try it once more time. Maybe I'Ve overseen something.
Let me get this straight. You have a dll, which links statically to Boost.Log. No other dlls or the application itself uses Boost.Log in any way (not even includes its headers). Your application links normally with your dll (no /delayload or LoadLibrary stuff). And the application crashes before entering main(). Also, you have RTTI and exceptions enabled when building all dll/exe. Is that all correct?
If so, then I don't see how this could be related to the DisableLogging parameter as the config file is only loaded from inside main(), unless I'm missing something. The only source of problems I can see is some global initialization issue. I can't tell anything more specific without symbol names.
What you can try:
Also, what gcc version do you use?
Hi Andrey,
I'm using MinGW. gcc version is 4.7.2.
As mentioned in the posts above. I've created a simple test application which links statically to the boost.log libraries (libboost_log_setup-mgw47-mt-1_53.a and libboost_log-mgw47-mt-1_53.a). Within this test executable I include my the boost.log specific logging environment, like stated in this code:
(Logging.cpp:
http://codeviewer.org/view/code:344e
"Logging.hpp"-file:
http://codeviewer.org/view/code:344f
).
Within the main application I first create a worker thread, which doesn't nothing except to invoke my boost.log-specific logging macro. After the worker thread has been created I also invoke my logging macro within the main. The crash happens...
In case I disable the creation of a worker thread within the main, everything goes fine with the loggging. Not crash, no SIGSEV...
You're right, I use the following configuration file to configure my boost.log-based mechanism. In case I turn the boost-logging in this configuration file off, no crash happens in the multi-thread-version of my test application.
The configuration file is read from within the main function. But please take a look here to understand the test application. http://codeviewer.org/view/code:344c
So please forget currently the DLL stuff. I have created the test application, as I was not sure, if the DLL causes the problems. But actually I figured out, that even in a simple and multi-threaded test application Boost.log seems to produce the crash on Windows XP-bases machines. Maybe the "msvcrt.dll" is not thread-safe...
...what would you suggest to continue with?
...ahh,
here is the configuration file:http://codeviewer.org/view/code:3454