log4cplus-devel — Mailing list for log4cplus developers

[Log4cplus-devel] [log4cplus:bugs] #332 AsyncAppender/RollingFileAppender combination error.

[Václav H. <wi...@us...>]

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -19,7 +19,8 @@
 After having modified the log properties file (and empty line is enough), the txt log file is never renamed to txt.1, however the file is still cleared when reaching filesize limit and logging continues from scratch. Furthermore the renaming/deletion of any remaining txt.\* files are still done, so that at some point only the .txt file remains.
 
 Some debug log from log4cplus immedately after saving the log.properties file:
-*
+
+```
 log4cplus: Queue thread started.
 log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
 log4cplus: Queue thread started.
@@ -28,16 +29,13 @@
 log4cplus: Entering ConsoleAppender::close()..
 log4cplus: Destroying appender named [stdout].
 log4cplus: Destroying appender named [nteventlog].
-log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.2 to d:/wpslog/hppp/Core.log
-.txt.3
-log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.1 to d:/wpslog/hppp/Core.log
-.txt.2
-log4cplus: Renaming file d:/wpslog/hppp/Core.log.txt to d:/wpslog/hppp/Core.log.
-txt.1
+log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.2 to d:/wpslog/hppp/Core.log.txt.3
+log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.1 to d:/wpslog/hppp/Core.log.txt.2
+log4cplus: Renaming file d:/wpslog/hppp/Core.log.txt to d:/wpslog/hppp/Core.log.txt.1
 log4cplus:ERROR Failed to rename file from d:/wpslog/hppp/Core.log.txt to d:/wps
 log/hppp/Core.log.txt.1; error 13
 log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
-*
+```
 
 The behaviour is consistent.
 If changing the appender to be RollingFileAppender only (without AsyncAppender) the issue dissappears.

~~~~

- **assigned_to**: Václav Haisman



---

** [bugs:#332] AsyncAppender/RollingFileAppender combination error.**

**Status:** open
**Group:** v1.2.0
**Created:** Mon Jun 13, 2016 12:57 PM UTC by Jakob Krogh Bodilsen
**Last Updated:** Mon Jan 30, 2017 02:46 PM UTC
**Owner:** Václav Haisman


We are using AsyncAppender combined with RollingFileAppender in the following manner:

~~~
log4cplus.appender.logfile=log4cplus::AsyncAppender
log4cplus.appender.logfile.QueueLimit=10000
log4cplus.appender.logfile.Appender =log4cplus::RollingFileAppender
log4cplus.appender.logfile.Appender.layout=log4cplus::PatternLayout
log4cplus.appender.logfile.Appender.BufferSize=10000
log4cplus.appender.logfile.Appender.ImmediateFlush=true
log4cplus.appender.logfile.Appender.File=d:/wpslog/hppp/Core.log.txt
log4cplus.appender.logfile.Appender.DatePattern='.'yyyy-MM-dd
log4cplus.appender.logfile.Appender.MaxFileSize=250KB
log4cplus.appender.logfile.Appender.MaxBackupIndex=10
log4cplus.appender.logfile.Appender.layout.ConversionPattern=%D{%Y-%m-%d %H:%M:%S.%q} [%t] %-5p %c - %m%n
~~~

The same process logs to several appenders. Several threads in this process logs to the appender above, but only this one process uses the appender.
After processstart the rollingfile logic works as expected.
After having modified the log properties file (and empty line is enough), the txt log file is never renamed to txt.1, however the file is still cleared when reaching filesize limit and logging continues from scratch. Furthermore the renaming/deletion of any remaining txt.\* files are still done, so that at some point only the .txt file remains.

Some debug log from log4cplus immedately after saving the log.properties file:

```
log4cplus: Queue thread started.
log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
log4cplus: Queue thread started.
log4cplus: Just opened file: d:/wpslog/hppp/timeStatisticLogFile.log.txt
log4cplus: Queue thread started.
log4cplus: Entering ConsoleAppender::close()..
log4cplus: Destroying appender named [stdout].
log4cplus: Destroying appender named [nteventlog].
log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.2 to d:/wpslog/hppp/Core.log.txt.3
log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.1 to d:/wpslog/hppp/Core.log.txt.2
log4cplus: Renaming file d:/wpslog/hppp/Core.log.txt to d:/wpslog/hppp/Core.log.txt.1
log4cplus:ERROR Failed to rename file from d:/wpslog/hppp/Core.log.txt to d:/wps
log/hppp/Core.log.txt.1; error 13
log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
```

The behaviour is consistent.
If changing the appender to be RollingFileAppender only (without AsyncAppender) the issue dissappears.
Any help is appreciated.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] Re: #332 AsyncAppender/RollingFileAppender combination error.

[Václav H. <wi...@us...>]

Hmm... It could be that the re-configuration does not close the rolling file appender file properly.

What is the "latest build" that you have used? I have fixed some issues related to `AsyncAppender` only very recently.



---

** [bugs:#332] AsyncAppender/RollingFileAppender combination error.**

**Status:** open
**Group:** v1.2.0
**Created:** Mon Jun 13, 2016 12:57 PM UTC by Jakob Krogh Bodilsen
**Last Updated:** Mon Jan 30, 2017 02:46 PM UTC
**Owner:** nobody


We are using AsyncAppender combined with RollingFileAppender in the following manner:

~~~
log4cplus.appender.logfile=log4cplus::AsyncAppender
log4cplus.appender.logfile.QueueLimit=10000
log4cplus.appender.logfile.Appender =log4cplus::RollingFileAppender
log4cplus.appender.logfile.Appender.layout=log4cplus::PatternLayout
log4cplus.appender.logfile.Appender.BufferSize=10000
log4cplus.appender.logfile.Appender.ImmediateFlush=true
log4cplus.appender.logfile.Appender.File=d:/wpslog/hppp/Core.log.txt
log4cplus.appender.logfile.Appender.DatePattern='.'yyyy-MM-dd
log4cplus.appender.logfile.Appender.MaxFileSize=250KB
log4cplus.appender.logfile.Appender.MaxBackupIndex=10
log4cplus.appender.logfile.Appender.layout.ConversionPattern=%D{%Y-%m-%d %H:%M:%S.%q} [%t] %-5p %c - %m%n
~~~

The same process logs to several appenders. Several threads in this process logs to the appender above, but only this one process uses the appender.
After processstart the rollingfile logic works as expected.
After having modified the log properties file (and empty line is enough), the txt log file is never renamed to txt.1, however the file is still cleared when reaching filesize limit and logging continues from scratch. Furthermore the renaming/deletion of any remaining txt.\* files are still done, so that at some point only the .txt file remains.

Some debug log from log4cplus immedately after saving the log.properties file:
*
log4cplus: Queue thread started.
log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
log4cplus: Queue thread started.
log4cplus: Just opened file: d:/wpslog/hppp/timeStatisticLogFile.log.txt
log4cplus: Queue thread started.
log4cplus: Entering ConsoleAppender::close()..
log4cplus: Destroying appender named [stdout].
log4cplus: Destroying appender named [nteventlog].
log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.2 to d:/wpslog/hppp/Core.log
.txt.3
log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.1 to d:/wpslog/hppp/Core.log
.txt.2
log4cplus: Renaming file d:/wpslog/hppp/Core.log.txt to d:/wpslog/hppp/Core.log.
txt.1
log4cplus:ERROR Failed to rename file from d:/wpslog/hppp/Core.log.txt to d:/wps
log/hppp/Core.log.txt.1; error 13
log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
*

The behaviour is consistent.
If changing the appender to be RollingFileAppender only (without AsyncAppender) the issue dissappears.
Any help is appreciated.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #332 AsyncAppender/RollingFileAppender combination error.

[Jan M. <jmo...@us...>]

Hi Václav.
I have just retested this problem with the latest build and it is still an issue.
As Jakob describes above the rolling file functionality works fine (with 10 backlog files); renaming and everything.
So it works fine until the moment that you change the configuration. After that it starts removing the old files and you end up with a something that looks like bug ###

I am a colleague  to Jakob.


---

** [bugs:#332] AsyncAppender/RollingFileAppender combination error.**

**Status:** open
**Group:** v1.2.0
**Created:** Mon Jun 13, 2016 12:57 PM UTC by Jakob Krogh Bodilsen
**Last Updated:** Thu Jul 07, 2016 06:31 AM UTC
**Owner:** nobody


We are using AsyncAppender combined with RollingFileAppender in the following manner:

~~~
log4cplus.appender.logfile=log4cplus::AsyncAppender
log4cplus.appender.logfile.QueueLimit=10000
log4cplus.appender.logfile.Appender =log4cplus::RollingFileAppender
log4cplus.appender.logfile.Appender.layout=log4cplus::PatternLayout
log4cplus.appender.logfile.Appender.BufferSize=10000
log4cplus.appender.logfile.Appender.ImmediateFlush=true
log4cplus.appender.logfile.Appender.File=d:/wpslog/hppp/Core.log.txt
log4cplus.appender.logfile.Appender.DatePattern='.'yyyy-MM-dd
log4cplus.appender.logfile.Appender.MaxFileSize=250KB
log4cplus.appender.logfile.Appender.MaxBackupIndex=10
log4cplus.appender.logfile.Appender.layout.ConversionPattern=%D{%Y-%m-%d %H:%M:%S.%q} [%t] %-5p %c - %m%n
~~~

The same process logs to several appenders. Several threads in this process logs to the appender above, but only this one process uses the appender.
After processstart the rollingfile logic works as expected.
After having modified the log properties file (and empty line is enough), the txt log file is never renamed to txt.1, however the file is still cleared when reaching filesize limit and logging continues from scratch. Furthermore the renaming/deletion of any remaining txt.\* files are still done, so that at some point only the .txt file remains.

Some debug log from log4cplus immedately after saving the log.properties file:
*
log4cplus: Queue thread started.
log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
log4cplus: Queue thread started.
log4cplus: Just opened file: d:/wpslog/hppp/timeStatisticLogFile.log.txt
log4cplus: Queue thread started.
log4cplus: Entering ConsoleAppender::close()..
log4cplus: Destroying appender named [stdout].
log4cplus: Destroying appender named [nteventlog].
log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.2 to d:/wpslog/hppp/Core.log
.txt.3
log4cplus: Renamed file d:/wpslog/hppp/Core.log.txt.1 to d:/wpslog/hppp/Core.log
.txt.2
log4cplus: Renaming file d:/wpslog/hppp/Core.log.txt to d:/wpslog/hppp/Core.log.
txt.1
log4cplus:ERROR Failed to rename file from d:/wpslog/hppp/Core.log.txt to d:/wps
log/hppp/Core.log.txt.1; error 13
log4cplus: Just opened file: d:/wpslog/hppp/Core.log.txt
*

The behaviour is consistent.
If changing the appender to be RollingFileAppender only (without AsyncAppender) the issue dissappears.
Any help is appreciated.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #328 log4cplus::HierarchyLocker DTor breaks no throw guarantee

[Václav H. <wi...@us...>]

- **status**: open --> closed
- **assigned_to**: Václav Haisman



---

** [bugs:#328] log4cplus::HierarchyLocker DTor breaks no throw guarantee**

**Status:** closed
**Group:** v1.2.x
**Created:** Wed Mar 30, 2016 08:44 AM UTC by Christian Stolle
**Last Updated:** Sun Jan 29, 2017 10:40 PM UTC
**Owner:** Václav Haisman


Release version: log4cplus-1.2.0
Build system: Visual Studio 2015
Project configuration: all
target OS and CPU: Windows 7, i7-4790K

log4cplus::HierarchyLocker::~HierarchyLocker rethrows catched exceptions (hierarchylocker.cxx, line 73). This may lead under certain circumstances to an unintended std::terminate. In c++11 nothrow is implicitly assumed for destructors. 


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #328 log4cplus::HierarchyLocker DTor breaks no throw guarantee

[Václav H. <wi...@us...>]

This is now fixed on all active branches.


---

** [bugs:#328] log4cplus::HierarchyLocker DTor breaks no throw guarantee**

**Status:** open
**Group:** v1.2.x
**Created:** Wed Mar 30, 2016 08:44 AM UTC by Christian Stolle
**Last Updated:** Wed Mar 30, 2016 08:44 AM UTC
**Owner:** nobody


Release version: log4cplus-1.2.0
Build system: Visual Studio 2015
Project configuration: all
target OS and CPU: Windows 7, i7-4790K

log4cplus::HierarchyLocker::~HierarchyLocker rethrows catched exceptions (hierarchylocker.cxx, line 73). This may lead under certain circumstances to an unintended std::terminate. In c++11 nothrow is implicitly assumed for destructors. 


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #186 Milli- and Micro-second time format

[Václav H. <wi...@us...>]

- **status**: pending --> closed



---

** [bugs:#186] Milli- and Micro-second time format**

**Status:** closed
**Group:** v1.1.x
**Labels:** enhancement 
**Created:** Wed Sep 24, 2003 12:22 PM UTC by Caleb Epstein
**Last Updated:** Wed Aug 14, 2013 09:17 AM UTC
**Owner:** Václav Haisman


I think the %q and %Q extensions to strftime should accept a use-leading-zeroes modifier \(e.g. %03q\) or be formatted with leading zeroes by default.  The current format makes sorting and matching difficult.

Also, there should be another extension for getting the time in microseconds.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #334 this may be a rarely occurred bug of AsyncAppender

[Václav H. <wi...@us...>]

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -1,7 +1,8 @@
 sorry for my poor english first...
 
 the code is in /src/queue.cxx, the function "get_events", 
-~~~
+
+~~~{.cpp}
             else if (((EXIT | QUEUE) & flags) == (EXIT | QUEUE))
             {
                 assert (! queue.empty ());

~~~~




---

** [bugs:#334] this may be a rarely occurred bug of AsyncAppender**

**Status:** open
**Group:** v1.1.3
**Created:** Fri Sep 02, 2016 12:20 PM UTC by owenliang
**Last Updated:** Sun Jan 29, 2017 10:08 PM UTC
**Owner:** nobody


sorry for my poor english first...

the code is in /src/queue.cxx, the function "get_events", 

~~~{.cpp}
            else if (((EXIT | QUEUE) & flags) == (EXIT | QUEUE))
            {
                assert (! queue.empty ());
                queue.clear ();
                flags &= ~QUEUE;
                ev_consumer.reset ();
                sem.unlock (); // look at here
                ret_flags = flags;
                break;
            }
~~~

the story goes like this:

1, all threads that is calling "asyncAppender::append()" hang on the Semaphore of queue, because the consumer thread is doing a heavy IO outputing and then has no time to process the queue full of events.
2, one of these threads' sem_wait is interrupt by a signal, then AsyncAppender::append() will call queue::signal_eixt(false) to terminal the consumer thread. (flags=EXIT|QUEUE)
3, consumer thread finish IO and loop again, then will go into the code above in the next loop.
4, sem.unlock() is just called once, and then the consumer thread exit.
5, all the other threads which is hanging on Semaphore will never exit.

take a look && help me , thanks.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #334 this may be a rarely occurred bug of AsyncAppender

[Václav H. <wi...@us...>]

Change set [9f570f078d619ed722f54737678599c3d3aaef20](https://github.com/wilx/log4cplus/commit/9f570f078d619ed722f54737678599c3d3aaef20) should fix this issue.


---

** [bugs:#334] this may be a rarely occurred bug of AsyncAppender**

**Status:** open
**Group:** v1.1.3
**Created:** Fri Sep 02, 2016 12:20 PM UTC by owenliang
**Last Updated:** Sun Jan 29, 2017 09:41 PM UTC
**Owner:** nobody


sorry for my poor english first...

the code is in /src/queue.cxx, the function "get_events", 
~~~
            else if (((EXIT | QUEUE) & flags) == (EXIT | QUEUE))
            {
                assert (! queue.empty ());
                queue.clear ();
                flags &= ~QUEUE;
                ev_consumer.reset ();
                sem.unlock (); // look at here
                ret_flags = flags;
                break;
            }
~~~

the story goes like this:

1, all threads that is calling "asyncAppender::append()" hang on the Semaphore of queue, because the consumer thread is doing a heavy IO outputing and then has no time to process the queue full of events.
2, one of these threads' sem_wait is interrupt by a signal, then AsyncAppender::append() will call queue::signal_eixt(false) to terminal the consumer thread. (flags=EXIT|QUEUE)
3, consumer thread finish IO and loop again, then will go into the code above in the next loop.
4, sem.unlock() is just called once, and then the consumer thread exit.
5, all the other threads which is hanging on Semaphore will never exit.

take a look && help me , thanks.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #334 this may be a rarely occurred bug of AsyncAppender

[Václav H. <wi...@us...>]

I did not realize that `sem_wait()` was interruptible by signals. I will add a loop similar to those that are there for `write()` and `read()`.


---

** [bugs:#334] this may be a rarely occurred bug of AsyncAppender**

**Status:** open
**Group:** v1.1.3
**Created:** Fri Sep 02, 2016 12:20 PM UTC by owenliang
**Last Updated:** Fri Sep 02, 2016 12:20 PM UTC
**Owner:** nobody


sorry for my poor english first...

the code is in /src/queue.cxx, the function "get_events", 
~~~
            else if (((EXIT | QUEUE) & flags) == (EXIT | QUEUE))
            {
                assert (! queue.empty ());
                queue.clear ();
                flags &= ~QUEUE;
                ev_consumer.reset ();
                sem.unlock (); // look at here
                ret_flags = flags;
                break;
            }
~~~

the story goes like this:

1, all threads that is calling "asyncAppender::append()" hang on the Semaphore of queue, because the consumer thread is doing a heavy IO outputing and then has no time to process the queue full of events.
2, one of these threads' sem_wait is interrupt by a signal, then AsyncAppender::append() will call queue::signal_eixt(false) to terminal the consumer thread. (flags=EXIT|QUEUE)
3, consumer thread finish IO and loop again, then will go into the code above in the next loop.
4, sem.unlock() is just called once, and then the consumer thread exit.
5, all the other threads which is hanging on Semaphore will never exit.

take a look && help me , thanks.


---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #336 Build error on Solaris Sparc under gcc - constructor priorities are not supported

[Václav H. <wi...@us...>]

- **status**: open --> closed
- **assigned_to**: Václav Haisman



---

** [bugs:#336] Build error on Solaris Sparc under gcc - constructor priorities are not supported**

**Status:** closed
**Group:** v1.1.3
**Created:** Fri Sep 30, 2016 05:54 PM UTC by Jon Harvie
**Last Updated:** Sun Jan 29, 2017 09:31 PM UTC
**Owner:** Václav Haisman


Release 1.1.3-RC7 fails to build on Solaris Sparc with gcc 4.9.2 due to the following error.

```
In file included from global-init.cxx:21:0:
../include/log4cplus/config.hxx:150:46: error: constructor priorities are not supported
     __attribute__ ((__constructor__ ((prio))))
                                              ^
global-init.cxx:608:5: note: in expansion of macro 'LOG4CPLUS_CONSTRUCTOR_FUNC'
     LOG4CPLUS_CONSTRUCTOR_FUNC (LOG4CPLUS_INIT_PRIORITY_BASE);
     ^
```

It appears that the configure scripts and macros are assuming that if the GCC constructor attribute is supported then construction priority is also supported. 



---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #336 Build error on Solaris Sparc under gcc - constructor priorities are not supported

[Václav H. <wi...@us...>]

I have just pushed [da867ad2fcc4b8220c3b1b66cc4f2b12b75d3a73](https://github.com/wilx/log4cplus/commit/da867ad2fcc4b8220c3b1b66cc4f2b12b75d3a73) to 1.1.x branch which fixes this.


---

** [bugs:#336] Build error on Solaris Sparc under gcc - constructor priorities are not supported**

**Status:** open
**Group:** v1.1.3
**Created:** Fri Sep 30, 2016 05:54 PM UTC by Jon Harvie
**Last Updated:** Sun Jan 29, 2017 09:15 PM UTC
**Owner:** nobody


Release 1.1.3-RC7 fails to build on Solaris Sparc with gcc 4.9.2 due to the following error.

```
In file included from global-init.cxx:21:0:
../include/log4cplus/config.hxx:150:46: error: constructor priorities are not supported
     __attribute__ ((__constructor__ ((prio))))
                                              ^
global-init.cxx:608:5: note: in expansion of macro 'LOG4CPLUS_CONSTRUCTOR_FUNC'
     LOG4CPLUS_CONSTRUCTOR_FUNC (LOG4CPLUS_INIT_PRIORITY_BASE);
     ^
```

It appears that the configure scripts and macros are assuming that if the GCC constructor attribute is supported then construction priority is also supported. 



---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #336 Build error on Solaris Sparc under gcc - constructor priorities are not supported

[Václav H. <wi...@us...>]

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -1,5 +1,6 @@
 Release 1.1.3-RC7 fails to build on Solaris Sparc with gcc 4.9.2 due to the following error.
 
+```
 In file included from global-init.cxx:21:0:
 ../include/log4cplus/config.hxx:150:46: error: constructor priorities are not supported
      __attribute__ ((__constructor__ ((prio))))
@@ -7,5 +8,6 @@
 global-init.cxx:608:5: note: in expansion of macro 'LOG4CPLUS_CONSTRUCTOR_FUNC'
      LOG4CPLUS_CONSTRUCTOR_FUNC (LOG4CPLUS_INIT_PRIORITY_BASE);
      ^
+```
 
 It appears that the configure scripts and macros are assuming that if the GCC constructor attribute is supported then construction priority is also supported. 

~~~~




---

** [bugs:#336] Build error on Solaris Sparc under gcc - constructor priorities are not supported**

**Status:** open
**Group:** v1.1.3
**Created:** Fri Sep 30, 2016 05:54 PM UTC by Jon Harvie
**Last Updated:** Fri Sep 30, 2016 05:54 PM UTC
**Owner:** nobody


Release 1.1.3-RC7 fails to build on Solaris Sparc with gcc 4.9.2 due to the following error.

```
In file included from global-init.cxx:21:0:
../include/log4cplus/config.hxx:150:46: error: constructor priorities are not supported
     __attribute__ ((__constructor__ ((prio))))
                                              ^
global-init.cxx:608:5: note: in expansion of macro 'LOG4CPLUS_CONSTRUCTOR_FUNC'
     LOG4CPLUS_CONSTRUCTOR_FUNC (LOG4CPLUS_INIT_PRIORITY_BASE);
     ^
```

It appears that the configure scripts and macros are assuming that if the GCC constructor attribute is supported then construction priority is also supported. 



---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] [log4cplus:bugs] #335 AsyncAppender leads to memory leaks

[Václav H. <wi...@us...>]

I have fixed a memory leak in `AsyncAppender` on close that was detectable on Linux. Hopefully, this will also solve issues for Windows. 


---

** [bugs:#335] AsyncAppender leads to memory leaks**

**Status:** open
**Group:** v1.2.0
**Labels:** AsyncAppender memory leaks 
**Created:** Thu Sep 15, 2016 01:34 AM UTC by davy
**Last Updated:** Thu Sep 15, 2016 05:56 AM UTC
**Owner:** Václav Haisman


**When i use the AsyncAppender in V1.2.0, VS2010 had detected many memory leaks like this:**

```
{2713} normal block at 0x00000000039C3070, 40 bytes long. Data: <@ I > 40 8B 49 00 00 00 00 00 FF FF FF FF 00 00 00 00
{2712} normal block at 0x00000000039BE0B0, 72 bytes long. Data: < @ @ > 08 EE 86 40 01 00 00 00 10 EE 86 40 01 00 00 00
{2711} normal block at 0x00000000039C1F40, 40 bytes long. Data: < I > E0 8A 49 00 00 00 00 00 FF FF FF FF 00 00 00 00
{2710} normal block at 0x00000000039BE000, 64 bytes long. Data: <(z @ 8z @ > 28 7A 87 40 01 00 00 00 38 7A 87 40 01 00 00 00
{2709} normal block at 0x00000000039C1ED0, 8 bytes long. Data: < > E4 01 00 00 00 00 00 00
{2708} normal block at 0x00000000039BDA00, 8 bytes long. Data: < > E0 01 00 00 00 00 00 00
{2707} normal block at 0x00000000039C1E40, 40 bytes long. Data: < I > 80 8A 49 00 00 00 00 00 FF FF FF FF 00 00 00 00
{2706} normal block at 0x00000000039BF370, 16 bytes long. Data: < > 18 A2 9B 03 00 00 00 00 00 00 00 00 00 00 00 00
{2705} normal block at 0x00000000039BF2E0, 40 bytes long. Data: < I > 20 8A 49 00 00 00 00 00 FF FF FF FF 00 00 00 00
{2704} normal block at 0x00000000039BA210, 112 bytes long. Data: < @ p > B8 C4 87 40 01 00 00 00 70 F3 9B 03 00 00 00 00
{2701} normal block at 0x00000000039B9300, 8 bytes long. Data: < > 00 00 00 00 00 00 00 00
{2309} normal block at 0x00000000039C1DC0, 16 bytes long. Data: < > 80 A4 9B 03 00 00 00 00 00 00 00 00 00 00 00 00
{2308} normal block at 0x00000000039C1D30, 40 bytes long. Data: <p=E > 70 3D 45 00 00 00 00 00 FF FF FF FF 00 00 00 00
{2307} normal block at 0x00000000039C1CB0, 16 bytes long. Data: < - @ > 88 2D 87 40 01 00 00 00 01 CD CD CD CD CD CD CD
{2306} normal block at 0x00000000039C0E70, 16 bytes long. Data: < > 18 A4 9B 03 00 00 00 00 00 00 00 00 00 00 00 00
{2305} normal block at 0x00000000039C0DF0, 16 bytes long. Data: < @ @ > 90 8C 87 40 01 00 00 00 40 06 9B 03 00 00 00 00
{2304} normal block at 0x00000000039BA540, 40 bytes long. Data: <P<E > 50 3C 45 00 00 00 00 00 FF FF FF FF 00 00 00 00
{2303} normal block at 0x00000000039BA400, 208 bytes long. Data: < | @ H| @ > 08 7C 87 40 01 00 00 00 48 7C 87 40 01 00 00 00
```



---

Sent from sourceforge.net because log...@li... is subscribed to https://sourceforge.net/p/log4cplus/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/log4cplus/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Log4cplus-devel] log4cplus 1.2.1-RC1 released

[Václav H. <vha...@gm...>]

I have released log4cplus 1.2.1-RC1
<https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.2.1/>.
It is a bugfix release.

  *

    Fixed GitHub issue #205. Fixed |AsyncAppender| shutdown crash.

  *

    Fixed GitHub bug #195. Check if queue thread pointer is not NULL and
    if it is running before trying to join it.

  *

    Fixed GitHub bug #136. Adjust weekly, daily and twice daily rollover
    time for |DailyRollingFileAppender| by time zone offset so that the
    rollover happens at midnight, etc., of local time instead of UTC time.

  *

    Fixed GitHub bug #148. |TTCCLayout| boolean members could be left
    uninitialized. Initialize them.

  *

    Fixed GitHub bug #163. Fixed Visual Studio 2015 build with CMake.
    Compilation fails not finding |FreeAddrInfoW()|.

  *

    Disabled use of |__thread| on iOS.

  *

    Fixed SF#333. |AsyncAppender|‘s appenders need to be closed so that
    accumulated logs get flushed onto disk.

  *

    Updated |android.toolchain.cmake| from OpenCV project.

​

-- 
VH

[Log4cplus-devel] log4cplus 1.1.3-RC7 released

[Václav H. <vha...@gm...>]

Hi.

I have release log4cplus 1.1.3-RC7
<https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.1.3/>.
It is a bugs fixing release:

  *

    Fixed SF#322 <https://sourceforge.net/p/log4cplus/bugs/322/>. —
    C++11 construct that should not be present.

  *

    Fixed |FreeAddrInfoA| and |FreeAddrInfoW| not found. — This required
    bump to minimal version to Windows XP SP2.

  *

    Fixed missing thread’s alternative name. — GitHub bug #137
    <https://github.com/log4cplus/log4cplus/issues/137>.

  *

    Fixed GitHub bug #155
    <https://github.com/log4cplus/log4cplus/issues/155>. — Process
    shutdown issues.

  *

    Fixed GitHub bug #136
    <https://github.com/log4cplus/log4cplus/issues/136>. — Adjust
    weekly, daily and twice daily rollover time for
    |DailyRollingFileAppender| by time zone offset so that the rollover
    happens at midnight, etc., of local time instead of UTC time.

  *

    Fixed CMake/Visual Studio 2010 compilation. — GitHub issue #188
    <https://github.com/log4cplus/log4cplus/issues/188>.

​
-- 

VH

Re: [Log4cplus-devel] windows 10 support in log4cplus

[Václav H. <vha...@gm...>]

On 21 March 2016 at 14:47, Hinrich Aue <Hin...@ko...> wrote:
> Hello list,
>
>
>
> can anybody tell me if windows 10 is supported and in which version?

I am not aware of any Windows 10 specific issues. TBH, I do not know
if I need to do anything to support Windows 10 specifically. I am open
to suggestions.

--VH

[Log4cplus-devel] windows 10 support in log4cplus

[Hinrich A. <Hin...@ko...>]

Hello list,

can anybody tell me if windows 10 is supported and in which version?

Thanks,
Hinrich


Hinrich Aue
Sr. Software Engineer
Kofax Development GmbH

Wentzinger Strasse 19
79106 Freiburg
Germany

Tel: +49 761 452 69 57234
Fax: +49 761 452 69 58734
Hin...@ko...

blog<http://www.kofax.com/blog/> | twitter<https://twitter.com/Kofax> | linkedin<https://www.linkedin.com/company/kofax> | facebook<https://www.facebook.com/kofax.inc> | talent network<http://www.jobs.net/jobs/Kofax-Inc/join>

________________________________

This communication is only for the use of the intended recipient. It may contain confidential or proprietary information. If you are not the intended recipient or have received this communication in error, please notify the sender via phone and destroy this communication immediately.
Kofax Development GmbH
Sitz der Gesellschaft: Freiburg i. Brg.
Registergericht: Amtsgericht Freiburg i.Br.
Registernummer: HRB 7007
Gesch?ftsf?hrer: Bradford Weller, Christian Hefner, Daniel Geiger

Re: [Log4cplus-devel] Disable console output

[Václav H. <vha...@gm...>]

On 14.1.2016 10:21, Gorbachev Ivan wrote:

>
> Hello! In my project i can't use config file, i need configure
> log4cplus only in code. How to disable console output in code ?

To avoid console output simply do not use any |ConsoleAppender|. You
will have to also avoid the easy way of configuring log4cplus through
|BasicConfigurator|. You can use |PropertyConfigurator| instead.

If you mean you want to avoid log4cplus diagnostic message to console,
you can enable quiet mode using |LogLog::setQuietMode(true)|. You can do
the same by having environment variable |LOG4CPLUS_LOGLOG_QUIETMODE=1| set.

​

-- 
VH

[Log4cplus-devel] log4cplus 1.2.0 released

[Václav H. <vha...@gm...>]

I have released log4cplus 1.2.0. The changes from the last release
candidate are minimal:

  *

    Fixed SourceForge bug #324, MinGW compilation issue. Use
    |InterlockedExchangeAdd| instead of |InterlockedAdd|. The former is
    supported by older MinGW.

  *

    Fixed GitHub bug #137. Fix missing thread’s alternative name.

​

-- 
VH

[Log4cplus-devel] Disable console output

[Gorbachev I. <gi...@gm...>]

Hello! In my project i can't use config file, i need configure log4cplus
only in code. How to disable console output in code ?

Re: [Log4cplus-devel] log4cplus 1.2.0-RC6 released

[Václav H. <vha...@gm...>]

On 1.1.2016 23:14, Václav Haisman wrote:

> I have released log4cplus 1.2.0-RC6
> <https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.2.0/>:
>
>  *
>
>     Fixed Visual Studio build issue #322
>     <https://sourceforge.net/p/log4cplus/bugs/322/> related to WinSock
>     functions being used and second about C++11 syntax. *This forces
>     minimum version of Windows supported by this release to Windows XP
>     SP3.*
>
This above line is incorrect. I have set the |NTDDI_VERSION| version to
|0x05010200| which is actually Windows XP *SP2*.

>  *
>  *
>
>     Added |DatePattern| property to |DailyRollingFileAppender|
>     configuration — This property specifies filename suffix pattern to
>     use for periodical backups of the logfile.
>
>  *
>
>     Added |RollOnClose| property to |DailyRollingFileAppender| and
>     |TimeBasedRollingFileAppender| configuration — This property
>     specifies whether to rollover log files upon shutdown. By default
>     it’s set to |true| to retain compatibility with legacy code.
>     (Alexey Morozov)
>
>  *
>
>     Normalized line endings, used |.gitattributes| to enforce it.
>
> ​
> -- 
> VH

​

-- 
VH

[Log4cplus-devel] log4cplus 1.2.0-RC6 released

[Václav H. <vha...@gm...>]

I have released log4cplus 1.2.0-RC6
<https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.2.0/>:

  *

    Fixed Visual Studio build issue #322
    <https://sourceforge.net/p/log4cplus/bugs/322/> related to WinSock
    functions being used and second about C++11 syntax. *This forces
    minimum version of Windows supported by this release to Windows XP SP3.*

  *

    Added |DatePattern| property to |DailyRollingFileAppender|
    configuration — This property specifies filename suffix pattern to
    use for periodical backups of the logfile.

  *

    Added |RollOnClose| property to |DailyRollingFileAppender| and
    |TimeBasedRollingFileAppender| configuration — This property
    specifies whether to rollover log files upon shutdown. By default
    it’s set to |true| to retain compatibility with legacy code. (Alexey
    Morozov)

  *

    Normalized line endings, used |.gitattributes| to enforce it.

​

-- 
VH

[Log4cplus-devel] log4cplus 1.2.0-RC5 released

[Václav H. <vha...@gm...>]

I have released log4cplus 1.2.0-RC5
<https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.2.0/>:

  *

    Various scripts and documentation cleanups.

  *

    Fix sockets and memory leak in |loggingserver| discussed in GitHub
    issue #112
    <https://github.com/log4cplus/log4cplus/issues/112#issuecomment-153003668>.

  *

    CMake improvements.

​

-- 
VH

[Log4cplus-devel] log4cplus 1.1.3-RC6 released

[Václav H. <vha...@gm...>]

Hi.

I have released log4cplus 1.1.3-RC6:

- Fixed GitHub issue #112 - sockets and memory leak in loggingserver.

-- 
VH

[Log4cplus-devel] log4cplus 1.2.0-RC4 released

[Václav H. <vha...@gm...>]

I have released log4cplus 1.2.0-RC4
<https://sourceforge.net/projects/log4cplus/files/log4cplus-stable/1.2.0/>.

  *

    Fixed |init_priority| GCC attribute detection and use issue.

  *

    Fixed “most vexing parse” issue with
    |LOG4CPLUS_C_STR_TO_TSTRING(STRING)| when |STRING| is an identifier.

  *

    Fixed |AcceptOnMatch| property function in filters default to true
    value.

  *

    Fixed GitHub bug #92
    <https://github.com/log4cplus/log4cplus/issues/92>.
    |DailyRollingFileAppender| rollover time was drifting.

  *

    Fixed GitHub bug #86
    <https://github.com/log4cplus/log4cplus/issues/86>. Create
    directories for lock file if |CreateDirs| is specified.

  *

    Allow turning off library name decoration in CMake builds. See also
    GitHub issue #98 <https://github.com/log4cplus/log4cplus/issues/98>.

​

-- 
VH