log4cplus-devel — Mailing list for log4cplus developers

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
Resolution: Accepted
Priority: 6
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-09-03 07:57

Message:
Good detective work. I have been able to reproduce the problem and I think
that the additional patch (attached) does fix the whole issue. Though I
will retest on few more systems than Cygwin later today to make sure.
Please test it as well.

----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 03:34

Message:
I lost my previous comment because fucking sourceforge logged me out while
I was writing it, so I'm sorry if this one is not very clear.

Please note that I can reproduce that bug on Ubuntu 12.04 too.

This patch does not fix the bug. However after some debugging session I
think I figured out the source:

http://linux.die.net/man/3/pthread_getspecific :
"Both pthread_getspecific() and pthread_setspecific() may be called from a
thread-specific data destructor function. A call to pthread_getspecific()
for the thread-specific data key being destroyed shall return the value
NULL"

This is consistent with what I'm seeing while debugging, which is:
- arg has the correct memory address
- tls_storage_key has the correct memory address
- tls_storage_key points to the value
- pthread_getspecific() returns 0 when given the correct tls_storage_key as
argument

So I think the second predicate of the assert() is not correct.

But I was wondering why it does not seem to happen often so I tried to dig
a bit in the code, and my best guess is that for some reason, most people
will end up with the first version of alloc_ptd() with the "special hack"
which makes the first predicate of the assert() return true. Moreover,
threadCleanup() doesn't fail because "delete ptd;" is deleting a null
pointer.

There's a strange line in ptd_cleanup_func(), "(void) arg;" does not seem
to do anything to me and I really wonder what it's doing there. Also, I
noticed that in threadCleanup() the last line is a call to
"internal::set_ptd (0);" and after that ptd_cleanup_func() will call
"thread::impl::tls_set_value (internal::tls_storage_key, 0));" so it seems
that the value of the key is set to 0 twice.

All of this in order to say that the thread cleanup code probably needs a
bit of cleanup too :)

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by gorpknalp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
Resolution: Accepted
Priority: 6
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: gorpknalp (gorpknalp)
Date: 2012-09-03 03:34

Message:
I lost my previous comment because fucking sourceforge logged me out while
I was writing it, so I'm sorry if this one is not very clear.

Please note that I can reproduce that bug on Ubuntu 12.04 too.

This patch does not fix the bug. However after some debugging session I
think I figured out the source:

http://linux.die.net/man/3/pthread_getspecific :
"Both pthread_getspecific() and pthread_setspecific() may be called from a
thread-specific data destructor function. A call to pthread_getspecific()
for the thread-specific data key being destroyed shall return the value
NULL"

This is consistent with what I'm seeing while debugging, which is:
- arg has the correct memory address
- tls_storage_key has the correct memory address
- tls_storage_key points to the value
- pthread_getspecific() returns 0 when given the correct tls_storage_key as
argument

So I think the second predicate of the assert() is not correct.

But I was wondering why it does not seem to happen often so I tried to dig
a bit in the code, and my best guess is that for some reason, most people
will end up with the first version of alloc_ptd() with the "special hack"
which makes the first predicate of the assert() return true. Moreover,
threadCleanup() doesn't fail because "delete ptd;" is deleting a null
pointer.

There's a strange line in ptd_cleanup_func(), "(void) arg;" does not seem
to do anything to me and I really wonder what it's doing there. Also, I
noticed that in threadCleanup() the last line is a call to
"internal::set_ptd (0);" and after that ptd_cleanup_func() will call
"thread::impl::tls_set_value (internal::tls_storage_key, 0));" so it seems
that the value of the key is set to 0 twice.

All of this in order to say that the thread cleanup code probably needs a
bit of cleanup too :)

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Re: [Log4cplus-devel] log4cplus 1.1.0-RC8 released

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

On 31 August 2012 16:52, mitch p wrote:
> syslog remote on windows is not push in factory if no syslog.h
>
> this ifdef is too selective if you want to propose that feature on windows
Bah, I have tested it only by manual instantiation in one of the
tests. Fixing...

>
> i find this feature very useful ;)
That nice to hear. :)

-- 
VZ

Re: [Log4cplus-devel] log4cplus 1.1.0-RC8 released

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

On 31 August 2012 16:33, Václav Zeman wrote:
> On 31 August 2012 15:26, mitch p wrote:
>> Hi,
>>
>> starting to play with log4cplus, I find a little error and a strange crash.
>>
>> 1 - in configurator.cxx, the code should be:
>>
>> void
>> ConfigurationWatchDogThread::updateLastModTime()
>> {
>>     helpers::FileInfo fi;
>>
>>     if (helpers::getFileInfo (&fi, propertyFilename) == 0)
>>         lastModTime = fi.mtime;
>> }
> Good catch. I have applied the change. I will push it into SF Bazaar
> repo later today.
>
>>
>> or lastModTime is never update
>>
>> 2 - in the config and watch test, if I leave internal debug on, the program
>> crash at exit, when destructors are call.
> I can see the crash as well. I am investigating it.
I think I have a fix for the issue. It is because of static variables
initialization/destruction order fiasco.

>
>>
>>
>> thanks and hope that help
> It does! :)


-- 
VZ

Re: [Log4cplus-devel] log4cplus 1.1.0-RC8 released

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

On 31 August 2012 15:26, mitch p wrote:
> Hi,
>
> starting to play with log4cplus, I find a little error and a strange crash.
>
> 1 - in configurator.cxx, the code should be:
>
> void
> ConfigurationWatchDogThread::updateLastModTime()
> {
>     helpers::FileInfo fi;
>
>     if (helpers::getFileInfo (&fi, propertyFilename) == 0)
>         lastModTime = fi.mtime;
> }
Good catch. I have applied the change. I will push it into SF Bazaar
repo later today.

>
> or lastModTime is never update
>
> 2 - in the config and watch test, if I leave internal debug on, the program
> crash at exit, when destructors are call.
I can see the crash as well. I am investigating it.

>
>
> thanks and hope that help
It does! :)

-- 
VZ

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Settings changed) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
Resolution: Accepted
>Priority: 6
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:33

Message:
This looks similar to the bug reported here:
https://sourceforge.net/tracker/?func=detail&aid=3467112&group_id=40830&atid=429075

I will apply the following change (later today, also attached). Please test
if it fixes your crash.

=== modified file 'src/global-init.cxx'
--- src/global-init.cxx	2012-08-29 18:59:41 +0000
+++ src/global-init.cxx	2012-08-31 12:16:36 +0000
@@ -293,7 +293,7 @@
     // Either it is a dummy value or it should be the per thread data
     // pointer we get from internal::get_ptd().
     assert (arg == reinterpret_cast<void *>(1)
-        || arg == internal::get_ptd ());
+        || arg == internal::get_ptd (false));
     (void)arg;
 
     threadCleanup ();


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3165465 ] please avoid windows.h in header files

[SourceForge.net <no...@so...>]

Bugs item #3165465, was opened at 2011-01-25 11:44
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3165465&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: v1.1.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: rjmyst3 (rjmyst3)
Assigned to: Václav Zeman (wilx)
Summary: please avoid windows.h in header files

Initial Comment:
Thank you very much for an excellent logging library. It is working very well for us, and we appreciate all the time you spend on it.
One problem that we are having is that windows.h is included indirectly via logger.h->config.hxx->thread-config.h

windows.h is a nasty header to impose on all users of logger.h and causes lots of problems.
Here are some examples of the problems that it causes:
Boost: https://svn.boost.org/trac/boost/ticket/1740
wxWidgets: "The windows.h Header File, Macros and Compiling Errors" http://wiki.wxwidgets.org/WxMSW_Issues#The_windows.h_Header_File.2C_Macros_and_Compiling_Errors
StackOverflow: http://stackoverflow.com/questions/4111899/is-there-an-easy-one-shot-solution-to-the-preprocessor-namespace-pollution-introd

Please create an abstraction layer that hides the use of windows.h from users of logger.h



----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:14

Message:
At this point in time I would suggest switching to 1.1.0-RC8. I am closing
this as fixed.


----------------------------------------------------------------------

Comment By: rjmyst3 (rjmyst3)
Date: 2011-04-11 05:48

Message:
I'm glad that you've already solved this in trunk.
We are really struggling to add log4cplus to our wxWidgets projects right
now. Is there a stable revision of trunk that we could switch to? What do
you recommend?

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2011-01-25 13:08

Message:
I have already hidden windows.h from public headers on SVN trunk. I will
try to port the changes back to the 1.0.x branch for 1.0.5. Thank you for
the bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3165465&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:06

Message:
Never mind, I have missed that you have attached files to this report.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
>Assigned to: Václav Zeman (wilx)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-31 05:05

Message:
Thank you for the bug report. Is it easily reproducible? I have had
something similar reported before this one but I were not able to reproduce
it myself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3563699 ] Assertion fails when boost thread terminates on Linux

[SourceForge.net <no...@so...>]

Bugs item #3563699, was opened at 2012-08-31 04:55
Message generated for change (Tracker Item Submitted) made by gorpknalp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion fails when boost thread terminates on Linux

Initial Comment:
When a boost thread uses a logger, and then terminates (under normal conditions), an assertion fails. This problem does not happen on Windows 7, only on my Raspberry Pi.

Using:
- log4cplus 1.1.0-rc8
- CMake build type debug with CMAKE_CXX_FLAGS="-std=c++0x"
- OS: Raspbian (derived from Debian ARM)

Client application using:
- shared library
- without wchar_t
- Boost 1.49

Error message:
cachip: /home/pi/prog/log4cplus-1.1.0-rc8/src/global-init.cxx:296: void log4cplus::ptd_cleanup_func(void*): Assertion `arg == reinterpret_cast<void *>(1) || arg == internal::get_ptd ()' failed.

Stack trace:
#0  0x402d9bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x402dd97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0x00022a08 in ?? ()
#3  0x00022a08 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3563699&group_id=40830

[Log4cplus-devel] [ log4cplus-Support Requests-3563229 ] Compiling with C++11 support

[SourceForge.net <no...@so...>]

Support Requests item #3563229, was opened at 2012-08-30 03:15
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.0
Status: Open
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Compiling with C++11 support

Initial Comment:
Hi,

I was trying to compile a program against log4cplus 1.1.0-rc8 on a new system (for the record, a Raspberry Pi), and had this error message:

Linking CXX executable cachip
CMakeFiles/cachip.dir/ServeClient.cpp.o: In function `ServeClient':
/home/pi/prog/cachip/cachip/ServeClient.cpp:40: undefined reference to `log4cplus::Logger::operator=(log4cplus::Logger&&)'
collect2: ld returned 1 exit status

This happens because I compiled log4cplus with CMake and no special CXXFLAG, while on the other hand my own program is compiled with -std=c++0x (on GCC 4.6). I'm not sure whether it is a bug or not as I'm not a package maintainer. I guess the library should be compiled unconditionally with C++11 support when the platform's compiler supports it.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-31 00:53

Message:
If I understand conclusions in some of GCC mailing list threads correctly,
binaries compiled for C++11 and C++03 will stay incompatible. IIRC there is
no way to really make them compatible. But I could be wrong. We will have
to wait and see what the GCC and other compilers' devs come up with.


----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-08-31 00:39

Message:
Out of curiosity, do you know of any official resource stating whether
C++03 and C++11 ABIs are supposed to be compatible or not? I can see some
discussions about GCC's incompatibilities but it's not very clear whether
it should be fixed in later versions or if separate libraries should be
built to support C++11. I'm surprised there's not been any outcry from
Linux distributions yet.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-30 07:31

Message:
Applications and libraries compiled for different languages (in this case
C++03 and C++11) are not binary compatible (at least not with GCC). This is
true for all libraries in general, not just for log4cplus. You have to
choose the language and specify it that for both log4cplus' compilation and
your application's compilation. To do that for log4cplus just add
-std=c++0x to CXXFLAGS on log4cplus' configure script command line.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

[Log4cplus-devel] [ log4cplus-Support Requests-3563229 ] Compiling with C++11 support

[SourceForge.net <no...@so...>]

Support Requests item #3563229, was opened at 2012-08-30 03:15
Message generated for change (Comment added) made by gorpknalp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.1.0
Status: Open
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Václav Zeman (wilx)
Summary: Compiling with C++11 support

Initial Comment:
Hi,

I was trying to compile a program against log4cplus 1.1.0-rc8 on a new system (for the record, a Raspberry Pi), and had this error message:

Linking CXX executable cachip
CMakeFiles/cachip.dir/ServeClient.cpp.o: In function `ServeClient':
/home/pi/prog/cachip/cachip/ServeClient.cpp:40: undefined reference to `log4cplus::Logger::operator=(log4cplus::Logger&&)'
collect2: ld returned 1 exit status

This happens because I compiled log4cplus with CMake and no special CXXFLAG, while on the other hand my own program is compiled with -std=c++0x (on GCC 4.6). I'm not sure whether it is a bug or not as I'm not a package maintainer. I guess the library should be compiled unconditionally with C++11 support when the platform's compiler supports it.

----------------------------------------------------------------------

Comment By: gorpknalp (gorpknalp)
Date: 2012-08-31 00:39

Message:
Out of curiosity, do you know of any official resource stating whether
C++03 and C++11 ABIs are supposed to be compatible or not? I can see some
discussions about GCC's incompatibilities but it's not very clear whether
it should be fixed in later versions or if separate libraries should be
built to support C++11. I'm surprised there's not been any outcry from
Linux distributions yet.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-30 07:31

Message:
Applications and libraries compiled for different languages (in this case
C++03 and C++11) are not binary compatible (at least not with GCC). This is
true for all libraries in general, not just for log4cplus. You have to
choose the language and specify it that for both log4cplus' compilation and
your application's compilation. To do that for log4cplus just add
-std=c++0x to CXXFLAGS on log4cplus' configure script command line.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

[Log4cplus-devel] [ log4cplus-Support Requests-3563229 ] Compiling with C++11 support

[SourceForge.net <no...@so...>]

Support Requests item #3563229, was opened at 2012-08-30 03:15
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: v1.1.0
Status: Open
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
>Assigned to: Václav Zeman (wilx)
Summary: Compiling with C++11 support

Initial Comment:
Hi,

I was trying to compile a program against log4cplus 1.1.0-rc8 on a new system (for the record, a Raspberry Pi), and had this error message:

Linking CXX executable cachip
CMakeFiles/cachip.dir/ServeClient.cpp.o: In function `ServeClient':
/home/pi/prog/cachip/cachip/ServeClient.cpp:40: undefined reference to `log4cplus::Logger::operator=(log4cplus::Logger&&)'
collect2: ld returned 1 exit status

This happens because I compiled log4cplus with CMake and no special CXXFLAG, while on the other hand my own program is compiled with -std=c++0x (on GCC 4.6). I'm not sure whether it is a bug or not as I'm not a package maintainer. I guess the library should be compiled unconditionally with C++11 support when the platform's compiler supports it.

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-30 07:31

Message:
Applications and libraries compiled for different languages (in this case
C++03 and C++11) are not binary compatible (at least not with GCC). This is
true for all libraries in general, not just for log4cplus. You have to
choose the language and specify it that for both log4cplus' compilation and
your application's compilation. To do that for log4cplus just add
-std=c++0x to CXXFLAGS on log4cplus' configure script command line.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

[Log4cplus-devel] [ log4cplus-Support Requests-3563229 ] Compiling with C++11 support

[SourceForge.net <no...@so...>]

Support Requests item #3563229, was opened at 2012-08-30 03:15
Message generated for change (Tracker Item Submitted) made by gorpknalp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: gorpknalp (gorpknalp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling with C++11 support

Initial Comment:
Hi,

I was trying to compile a program against log4cplus 1.1.0-rc8 on a new system (for the record, a Raspberry Pi), and had this error message:

Linking CXX executable cachip
CMakeFiles/cachip.dir/ServeClient.cpp.o: In function `ServeClient':
/home/pi/prog/cachip/cachip/ServeClient.cpp:40: undefined reference to `log4cplus::Logger::operator=(log4cplus::Logger&&)'
collect2: ld returned 1 exit status

This happens because I compiled log4cplus with CMake and no special CXXFLAG, while on the other hand my own program is compiled with -std=c++0x (on GCC 4.6). I'm not sure whether it is a bug or not as I'm not a package maintainer. I guess the library should be compiled unconditionally with C++11 support when the platform's compiler supports it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3563229&group_id=40830

[Log4cplus-devel] log4cplus 1.1.0-RC8 released

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

Hi.

I have released log4cplus 1.1.0-RC8. It contains some bug fixes and also
one new feature:

- Turned on __thread (TLS) detection on NetBSD 5.1.0 and later that
  has been previously disabled.

- Improved compatibility with log4cplus 1.0.x: allow using log4cplus
  1.0.x log level to string callbacks in 1.1.x.

- Improved various M4 macros.

- Added detection and use of C++11 thread_local.

- Fixed XML entities escaping in Log4jUdpAppender.

- Re-added synchronization between ConsoleAppender and LogLog.

- Changed C logger API to return int instead of bool.

- Added C logger API to Visual Studio 2010 projects.

- Implemented remote syslog logging using UDP in SysLogAppender.

- Enabled SysLogAppender on Windows with only remote syslog logging
  enabled.

-- 
VZ

[Log4cplus-devel] [ log4cplus-Support Requests-3560984 ] creating custom log level and setting it from prperty file

[SourceForge.net <no...@so...>]

Support Requests item #3560984, was opened at 2012-08-23 05:12
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3560984&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v1.0.4
Status: Pending
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Václav Zeman (wilx)
Summary: creating custom log level and setting it from prperty file

Initial Comment:
Hello,
I am trying to create custom log levels but I have faced these problems:
 1. I am not able to set custom log level from property file, log4cplus crashes (Getting error: log4cplus:ERROR LoggerImpl::getChainedLogLevel()- No valid LogLevel found);
 2. If I set custom log level in my program, then log level in log file is named: UNKNOWN;

Info about log4cplus:
Using static library
Version - 1.0.4
Build system - VisualStudio 2010 (project configuration is Debug)
Windows 7 SP1, 64bit

Config file:
log4cplus.rootLogger=TRACE1, Main
 
log4cplus.appender.Main=log4cplus::RollingFileAppender
log4cplus.appender.Main.File=myLogFile.log 
log4cplus.appender.Main.Append=true
log4cplus.appender.Main.MaxFileSize=10MB
log4cplus.appender.Main.MaxBackupIndex=50
log4cplus.appender.Main.layout=log4cplus::PatternLayout 
log4cplus.appender.Main.layout.ConversionPattern=%d | [%-7p] | %-20c | %-20m |%n 

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2012-08-28 06:38

Message:
I will try your suggestions next week.
Also I have noticed if log level is misspelled, then log4cplus (static
library) crashes with the same error as I have wrote earlier.
Thanks for suggestions.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-08-27 06:09

Message:
I could not reproduce the problem with log4cplus' test cases. But these
test cases are using log4cplus as a DLL. Could you try your code with
log4cplus as a DLL? Also/alternatively, could you test with the
pushToStringMethod() and pushFromStringMethod() calls moved into main()? I
suspect this might be an instance of static objects initialization order
fiasco problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429074&aid=3560984&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3539046 ] log4cplus.spec file fails in Fedora 14

[SourceForge.net <no...@so...>]

Bugs item #3539046, was opened at 2012-06-29 12:55
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3539046&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: v1.1.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brian (badrizzle)
Assigned to: Václav Zeman (wilx)
Summary: log4cplus.spec file fails in Fedora 14

Initial Comment:
when running rpmbuild -ta ~/rpmbuild/SOURCES/log4cplus-1.0.4.1.tar.gz  , several error occur

1)  "Copyright" is not recognized with rpmbuild, should be replaced with "License"
2)  the version number at top is "1.0.4", should be "1.0.4.1"
3) several headers in the include/log4cplus/config directory are not expected and thus rpmbuild breaks.

Attached is the spec file that I used that got me through everything.



----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-27 05:38

Message:
I believe this is now fixed on both 1.0.4.1 and trunk branches. If you
disagree, please reopen this bug report or submit a new one.

----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-07-14 06:10

Message:
Could you please check your rpmbuild with the attached log4cplus.spec file
instead? I think that your changes removing all of the log4cplus/config*
files is not correct. The attached spec file changes it to do this
instead:

rm -f $RPM_BUILD_ROOT%{prefix}/include/log4cplus/config/stamp-*
rm -f $RPM_BUILD_ROOT%{prefix}/include/log4cplus/config/*.in
rm -f $RPM_BUILD_ROOT%{prefix}/include/log4cplus/stamp-*

The log4cplus.spec file also contains some additional changes that I think
might be beneficial.


----------------------------------------------------------------------

Comment By: Václav Zeman (wilx)
Date: 2012-06-29 14:01

Message:
I have committed your version of the file to 1.0.4.1 branch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3539046&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3561263 ] PatternLayout: printing just the file name

[SourceForge.net <no...@so...>]

Bugs item #3561263, was opened at 2012-08-24 04:06
Message generated for change (Comment added) made by wilx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3561263&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Psychon (psychon)
>Assigned to: Václav Zeman (wilx)
Summary: PatternLayout: printing just the file name

Initial Comment:
Right now, when using %F in a pattern, the filename as seen by the compiler gets used. This can include parts of a relative path, especially for headers (but also when an out-of-tree build was used while compiling the source). This looks ugly.

I have two suggestions:
- Change %F (and %l) to just print the substring after the last directory seperator ("/" or "\", depending on OS).
- Add new modifiers that do the above.

Please let me know if you see this as an issue that should be fixed and which fix you would prefer.

Thanks,
Uli

----------------------------------------------------------------------

>Comment By: Václav Zeman (wilx)
Date: 2012-08-24 09:30

Message:
This is already implemented using %b specifier at least on trunk. .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3561263&group_id=40830

[Log4cplus-devel] [ log4cplus-Bugs-3561263 ] PatternLayout: printing just the file name

[SourceForge.net <no...@so...>]

Bugs item #3561263, was opened at 2012-08-24 04:06
Message generated for change (Tracker Item Submitted) made by psychon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3561263&group_id=40830

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Psychon (psychon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PatternLayout: printing just the file name

Initial Comment:
Right now, when using %F in a pattern, the filename as seen by the compiler gets used. This can include parts of a relative path, especially for headers (but also when an out-of-tree build was used while compiling the source). This looks ugly.

I have two suggestions:
- Change %F (and %l) to just print the substring after the last directory seperator ("/" or "\", depending on OS).
- Add new modifiers that do the above.

Please let me know if you see this as an issue that should be fixed and which fix you would prefer.

Thanks,
Uli

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=429073&aid=3561263&group_id=40830

Re: [Log4cplus-devel] compatibility question concerning log4cplus::tstring

[John L. <jl...@bl...>]

Hello Václav and thanks for the patch.

We've tried it and does indeed fix the problems we found and we can now build our same source tree against log4cplus 1.0.x and against the latest log4cplus 1.1.7+patch.   Many thanks.

John Lumby
Database Architect
BlueCat Networks Inc.

________________________________________
From: Václav Zeman [vha...@gm...]
Sent: Thursday, August 02, 2012 6:03 AM
To: John Lumby
Cc: log...@li...
Subject: Re: [Log4cplus-devel] compatibility question concerning log4cplus::tstring

On 2 August 2012 11:00, Václav Zeman wrote:
> On 1 August 2012 17:13, John Lumby wrote:
>> Hello,   I'd like to ask about compatibility of  log4cplus::tstring between 1.0.x and 1.1.x
> As I have written in reply in another thread, my intention has always
> been to keep log4cplus source compatible between versions.
>
>>
>> An application (bind10) has some code like so:
>>
>> // Convert logging level to string.  If the level is a valid debug level,
>> // return the string DEBUG, else return the empty string.
>> log4cplus::tstring
>> LoggerLevelImpl::logLevelToString(log4cplus::LogLevel level) {
>>     Level bindlevel = convertToBindLevel(level);
>>     Severity& severity = bindlevel.severity;
>>     int& dbglevel = bindlevel.dbglevel;
>>
>>     if ((severity == DEBUG) &&
>>         ((dbglevel >= MIN_DEBUG_LEVEL) && (dbglevel <= MAX_DEBUG_LEVEL))) {
>>         return (tstring("DEBUG"));
>>     }
>>
>>     // Unknown, so return empty string for log4cplus to try other conversion
>>     // functions.
>>     return (tstring());
>> }
>>
>> // Initialization.  Register the conversion functions with the LogLevelManager.
>> void
>> LoggerLevelImpl::init() {
>>
>>     // Get the singleton log-level manager.
>>     LogLevelManager& manager = getLogLevelManager();
>>
>>     // Register the conversion functions
>>     manager.pushFromStringMethod(LoggerLevelImpl::logLevelFromString);
>>     manager.pushToStringMethod(LoggerLevelImpl::logLevelToString);
>> }
>>
>> which compiles correctly against 1.0.x
>>
>> But compiling against 1.1.x results in
>>
>> logger_level_impl.cc:189:1: error: prototype for
>>          ‘const tstring& isc::log::LoggerLevelImpl::logLevelToString(log4cplus::LogLevel)’
>>       does not match any in class ‘isc::log::LoggerLevelImpl’
>> ../../../src/lib/log/logger_level_impl.h:115:31: error:
>>         candidate is: static log4cplus::tstring isc::log::LoggerLevelImpl::logLevelToString(log4cplus::LogLevel)
>>             In static member function ‘static void isc::log::LoggerLevelImpl::init()’:
>>
>> Changing the application code to read as follows fixes the problem ...
>>
>> // Convert logging level to string.  If the level is a valid debug level,
>> // return the string DEBUG, else return the empty string.
>> log4cplus::tstring const &
>> LoggerLevelImpl::logLevelToString(log4cplus::LogLevel level) {
>>
>>     static const tstring debug_string("DEBUG");
>>     static const tstring empty_string;
>>
>>     Level bindlevel = convertToBindLevel(level);
>>     Severity& severity = bindlevel.severity;
>>     int& dbglevel = bindlevel.dbglevel;
>>
>>     if ((severity == DEBUG) &&
>>         ((dbglevel >= MIN_DEBUG_LEVEL) && (dbglevel <= MAX_DEBUG_LEVEL))) {
>>         return (debug_string);
>>     }
>>
>>     // Unknown, so return empty string for log4cplus to try other conversion
>>     // functions.
>>     return (empty_string);
>> }
>>
>> but creates two new problems:
>>   .    code is less general  -   every possible string value which might be returned must be explicitly declared
>>           (fortunately there are only two  - "DEBUG" and "")
> I do not regard this as a problem. The set of log levels is intended
> to be small. The change of return type to reference to tstring is
> there for speed.
>
>>   .  code no longer compiles against 1.0.x  -
> This is a problem.  What you have discovered breaks the source
> compatibility intention and I am going to fix it by allowing both old
> and new callbacks.
>
>> logger_level_impl.cc: In static member function 'static void
>> isc::log::LoggerLevelImpl::init()':
>> logger_level_impl.cc:217: error: invalid conversion from 'const
>> log4cplus::tstring& (*)(log4cplus::LogLevel)' to 'log4cplus::tstring
>> (*)(log4cplus::LogLevel)'
>> logger_level_impl.cc:217: error:   initializing argument 1 of 'void
>> log4cplus::LogLevelManager::pushToStringMethod(log4cplus::tstring
>> (*)(log4cplus::LogLevel))'
>>
>> Has anyone else run into this?
>> And is it possible to write the application code for registering and running the logLevelToString() method in such a way that it
>> compiles correctly against both log4cplus releases?
I am attaching a patch that should allow using callbacks with both return types.

If there is any other source incompatibility, please let me know.

--
VZ

Re: [Log4cplus-devel] 1.1.0 compatible with 1.0.4

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

On 2 August 2012 10:52, Václav Zeman wrote:
> On 1 August 2012 16:07, Jeremy C. Reed wrote:
>> I didn't see any release notes in 1.1.0-RC6 (sorry I didn't try RC7 yet)
>> about any incompatibilities with 1.0.4.  Will there be any notes about
>> it or upgrade hints?  We want to support both versions.
> Even though it is not stated anywhere, my intention has always been to
> keep only source compatibility between versions.
>
>>
>> For example, to support two versions we have:
>>
>> #if (LOG4CPLUS_VERSION >= LOG4CPLUS_MAKE_VERSION(1, 1, 0))
>>     typedef log4cplus::tstring const & LogLevelString;
>> #else
>>     typedef log4cplus::tstring LogLevelString;
>> #endif
> I have seen the other email from John Lumby. While the change in the
> return type is intentional, I did not realize it would create this
> incompatibility. I guess that the onus is on log4cplus to fix this and
> provide a compatible interface. I will try to think of something.

One another source of incompatibility between 1.0.x and 1.1.x is the
return type of helpers::LogLog::getLogLog(). It is supposed to be used
only internally by log4cplus but it is part of public interface as
well. Its return type has changed from SharedObjectPtr<LogLog> to
LogLog *. Work around for this is not to try to cache the value
returned by helpers::LogLog::getLogLog() in a variable.

-- 
VZ

Re: [Log4cplus-devel] compatibility question concerning log4cplus::tstring

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

On 2 August 2012 11:00, Václav Zeman wrote:
> On 1 August 2012 17:13, John Lumby wrote:
>> Hello,   I'd like to ask about compatibility of  log4cplus::tstring between 1.0.x and 1.1.x
> As I have written in reply in another thread, my intention has always
> been to keep log4cplus source compatible between versions.
>
>>
>> An application (bind10) has some code like so:
>>
>> // Convert logging level to string.  If the level is a valid debug level,
>> // return the string DEBUG, else return the empty string.
>> log4cplus::tstring
>> LoggerLevelImpl::logLevelToString(log4cplus::LogLevel level) {
>>     Level bindlevel = convertToBindLevel(level);
>>     Severity& severity = bindlevel.severity;
>>     int& dbglevel = bindlevel.dbglevel;
>>
>>     if ((severity == DEBUG) &&
>>         ((dbglevel >= MIN_DEBUG_LEVEL) && (dbglevel <= MAX_DEBUG_LEVEL))) {
>>         return (tstring("DEBUG"));
>>     }
>>
>>     // Unknown, so return empty string for log4cplus to try other conversion
>>     // functions.
>>     return (tstring());
>> }
>>
>> // Initialization.  Register the conversion functions with the LogLevelManager.
>> void
>> LoggerLevelImpl::init() {
>>
>>     // Get the singleton log-level manager.
>>     LogLevelManager& manager = getLogLevelManager();
>>
>>     // Register the conversion functions
>>     manager.pushFromStringMethod(LoggerLevelImpl::logLevelFromString);
>>     manager.pushToStringMethod(LoggerLevelImpl::logLevelToString);
>> }
>>
>> which compiles correctly against 1.0.x
>>
>> But compiling against 1.1.x results in
>>
>> logger_level_impl.cc:189:1: error: prototype for
>>          ‘const tstring& isc::log::LoggerLevelImpl::logLevelToString(log4cplus::LogLevel)’
>>       does not match any in class ‘isc::log::LoggerLevelImpl’
>> ../../../src/lib/log/logger_level_impl.h:115:31: error:
>>         candidate is: static log4cplus::tstring isc::log::LoggerLevelImpl::logLevelToString(log4cplus::LogLevel)
>>             In static member function ‘static void isc::log::LoggerLevelImpl::init()’:
>>
>> Changing the application code to read as follows fixes the problem ...
>>
>> // Convert logging level to string.  If the level is a valid debug level,
>> // return the string DEBUG, else return the empty string.
>> log4cplus::tstring const &
>> LoggerLevelImpl::logLevelToString(log4cplus::LogLevel level) {
>>
>>     static const tstring debug_string("DEBUG");
>>     static const tstring empty_string;
>>
>>     Level bindlevel = convertToBindLevel(level);
>>     Severity& severity = bindlevel.severity;
>>     int& dbglevel = bindlevel.dbglevel;
>>
>>     if ((severity == DEBUG) &&
>>         ((dbglevel >= MIN_DEBUG_LEVEL) && (dbglevel <= MAX_DEBUG_LEVEL))) {
>>         return (debug_string);
>>     }
>>
>>     // Unknown, so return empty string for log4cplus to try other conversion
>>     // functions.
>>     return (empty_string);
>> }
>>
>> but creates two new problems:
>>   .    code is less general  -   every possible string value which might be returned must be explicitly declared
>>           (fortunately there are only two  - "DEBUG" and "")
> I do not regard this as a problem. The set of log levels is intended
> to be small. The change of return type to reference to tstring is
> there for speed.
>
>>   .  code no longer compiles against 1.0.x  -
> This is a problem.  What you have discovered breaks the source
> compatibility intention and I am going to fix it by allowing both old
> and new callbacks.
>
>> logger_level_impl.cc: In static member function 'static void
>> isc::log::LoggerLevelImpl::init()':
>> logger_level_impl.cc:217: error: invalid conversion from 'const
>> log4cplus::tstring& (*)(log4cplus::LogLevel)' to 'log4cplus::tstring
>> (*)(log4cplus::LogLevel)'
>> logger_level_impl.cc:217: error:   initializing argument 1 of 'void
>> log4cplus::LogLevelManager::pushToStringMethod(log4cplus::tstring
>> (*)(log4cplus::LogLevel))'
>>
>> Has anyone else run into this?
>> And is it possible to write the application code for registering and running the logLevelToString() method in such a way that it
>> compiles correctly against both log4cplus releases?
I am attaching a patch that should allow using callbacks with both return types.

If there is any other source incompatibility, please let me know.

-- 
VZ

Re: [Log4cplus-devel] compatibility question concerning log4cplus::tstring

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

On 1 August 2012 17:13, John Lumby wrote:
> Hello,   I'd like to ask about compatibility of  log4cplus::tstring between 1.0.x and 1.1.x
As I have written in reply in another thread, my intention has always
been to keep log4cplus source compatible between versions.

>
> An application (bind10) has some code like so:
>
> // Convert logging level to string.  If the level is a valid debug level,
> // return the string DEBUG, else return the empty string.
> log4cplus::tstring
> LoggerLevelImpl::logLevelToString(log4cplus::LogLevel level) {
>     Level bindlevel = convertToBindLevel(level);
>     Severity& severity = bindlevel.severity;
>     int& dbglevel = bindlevel.dbglevel;
>
>     if ((severity == DEBUG) &&
>         ((dbglevel >= MIN_DEBUG_LEVEL) && (dbglevel <= MAX_DEBUG_LEVEL))) {
>         return (tstring("DEBUG"));
>     }
>
>     // Unknown, so return empty string for log4cplus to try other conversion
>     // functions.
>     return (tstring());
> }
>
> // Initialization.  Register the conversion functions with the LogLevelManager.
> void
> LoggerLevelImpl::init() {
>
>     // Get the singleton log-level manager.
>     LogLevelManager& manager = getLogLevelManager();
>
>     // Register the conversion functions
>     manager.pushFromStringMethod(LoggerLevelImpl::logLevelFromString);
>     manager.pushToStringMethod(LoggerLevelImpl::logLevelToString);
> }
>
> which compiles correctly against 1.0.x
>
> But compiling against 1.1.x results in
>
> logger_level_impl.cc:189:1: error: prototype for
>          ‘const tstring& isc::log::LoggerLevelImpl::logLevelToString(log4cplus::LogLevel)’
>       does not match any in class ‘isc::log::LoggerLevelImpl’
> ../../../src/lib/log/logger_level_impl.h:115:31: error:
>         candidate is: static log4cplus::tstring isc::log::LoggerLevelImpl::logLevelToString(log4cplus::LogLevel)
>             In static member function ‘static void isc::log::LoggerLevelImpl::init()’:
>
> Changing the application code to read as follows fixes the problem ...
>
> // Convert logging level to string.  If the level is a valid debug level,
> // return the string DEBUG, else return the empty string.
> log4cplus::tstring const &
> LoggerLevelImpl::logLevelToString(log4cplus::LogLevel level) {
>
>     static const tstring debug_string("DEBUG");
>     static const tstring empty_string;
>
>     Level bindlevel = convertToBindLevel(level);
>     Severity& severity = bindlevel.severity;
>     int& dbglevel = bindlevel.dbglevel;
>
>     if ((severity == DEBUG) &&
>         ((dbglevel >= MIN_DEBUG_LEVEL) && (dbglevel <= MAX_DEBUG_LEVEL))) {
>         return (debug_string);
>     }
>
>     // Unknown, so return empty string for log4cplus to try other conversion
>     // functions.
>     return (empty_string);
> }
>
> but creates two new problems:
>   .    code is less general  -   every possible string value which might be returned must be explicitly declared
>           (fortunately there are only two  - "DEBUG" and "")
I do not regard this as a problem. The set of log levels is intended
to be small. The change of return type to reference to tstring is
there for speed.

>   .  code no longer compiles against 1.0.x  -
This is a problem.  What you have discovered breaks the source
compatibility intention and I am going to fix it by allowing both old
and new callbacks.

> logger_level_impl.cc: In static member function 'static void
> isc::log::LoggerLevelImpl::init()':
> logger_level_impl.cc:217: error: invalid conversion from 'const
> log4cplus::tstring& (*)(log4cplus::LogLevel)' to 'log4cplus::tstring
> (*)(log4cplus::LogLevel)'
> logger_level_impl.cc:217: error:   initializing argument 1 of 'void
> log4cplus::LogLevelManager::pushToStringMethod(log4cplus::tstring
> (*)(log4cplus::LogLevel))'
>
> Has anyone else run into this?
> And is it possible to write the application code for registering and running the logLevelToString() method in such a way that it
> compiles correctly against both log4cplus releases?

-- 
VZ

Re: [Log4cplus-devel] 1.1.0 compatible with 1.0.4

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

On 1 August 2012 16:07, Jeremy C. Reed wrote:
> I didn't see any release notes in 1.1.0-RC6 (sorry I didn't try RC7 yet)
> about any incompatibilities with 1.0.4.  Will there be any notes about
> it or upgrade hints?  We want to support both versions.
Even though it is not stated anywhere, my intention has always been to
keep only source compatibility between versions.

>
> For example, to support two versions we have:
>
> #if (LOG4CPLUS_VERSION >= LOG4CPLUS_MAKE_VERSION(1, 1, 0))
>     typedef log4cplus::tstring const & LogLevelString;
> #else
>     typedef log4cplus::tstring LogLevelString;
> #endif
I have seen the other email from John Lumby. While the change in the
return type is intentional, I did not realize it would create this
incompatibility. I guess that the onus is on log4cplus to fix this and
provide a compatible interface. I will try to think of something.

--
VZ