You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by deepak singh <de...@gmail.com> on 2009/07/30 07:56:44 UTC
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in
ObjectPtrBase
Use apr, apr-util, expat, log4cxx libraries compiled with -fPIC flag.
It works in my case.
On Thu, Jul 30, 2009 at 9:06 AM, Curt Arnold <ca...@apache.org> wrote:
>
> On Jul 16, 2009, at 7:43 AM, abgimeno wrote:
>
>
>> Hi
>>
>> I have the same problem and I could not solve. I have installed the
>> version
>> apache-log4cxx-0.10.0. apr-1.3.6 and apr-util-1.3.8. in a Red Hat 5 x64
>>
>> I tried with the patch 596934 and does not work.
>>
>>
>> When the program ends gives an exception
>>
>> terminate called after throwing an instance of
>> 'log4cxx::helpers::MutexException'
>> what(): Mutex exception: stat = 22
>> ./tester.sh: line 71: 17226 Aborted ./tester
>>
>>
> I'l try to fire up a copy of CentOS 5 x64 this weekend.
>
> Did it occur during the unit tests or one of the sample applications, or in
> some other context?
>
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in
ObjectPtrBase
Posted by Jade2k <ja...@hotmail.com>.
Let me retract that message above ---- the patch and with the option, did not
fix it.
First time running the application, it did this:
terminate called after throwing an instance of
'log4cxx::helpers::MutexException'
what(): Mutex exception: stat = 22
Aborted
Then rerunning it again with the same application, it did this:
terminate called after throwing an instance of
'log4cxx::helpers::MutexException'
what(): Mutex exception: stat = 1
Aborted
And then other times it just Segmentation fault
It looks like it's happening when the application exits. I run the same
application using a different logger, I don't have this crash or exceptions.
The only thing I could gather from the stack is:
Program received signal SIGSEGV, Segmentation fault.
allocator_alloc (newpool=0x7fffffffe0e0, parent=0x617c68, abort_fn=0,
allocator=0x613b50) at memory/unix/apr_pools.c:252
252 if ((*ref = node->next) == NULL && i >= max_index) {
(gdb) where
#0 allocator_alloc (newpool=0x7fffffffe0e0, parent=0x617c68, abort_fn=0,
allocator=0x613b50) at memory/unix/apr_pools.c:252
#1 apr_pool_create_ex (newpool=0x7fffffffe0e0, parent=0x617c68, abort_fn=0,
allocator=0x613b50) at memory/unix/apr_pools.c:856
#2 0x00002aaaaafb1060 in log4cxx::helpers::Pool::Pool (this=0x7fffffffe0e0)
at pool.cpp:34
#3 0x00002aaaaaf67692 in log4cxx::helpers::MutexException::formatMessage
(stat=22) at exception.cpp:227
#4 0x00002aaaaaf67739 in log4cxx::helpers::MutexException::MutexException
(this=0x624750, stat=2090152296) at exception.cpp:213
#5 0x00002aaaaafd3f77 in log4cxx::helpers::synchronized::synchronized
(this=<value optimized out>, mutex1=<value optimized out>)
at synchronized.cpp:35
#6 0x00002aaaaafe783d in log4cxx::WriterAppender::close
(this=0x2aaaac000b20) at writerappender.cpp:135
#7 0x00002aaaaaf6d369 in log4cxx::FileAppender::~FileAppender
(this=0x613b40, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at fileappender.cpp:88
#8 0x00002aaaaaf3e3f8 in
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>::~ObjectPtrT
(this=0x2aaaac000cc0,
__in_chrg=<value optimized out>) at
../../../src/main/include/log4cxx/helpers/objectptr.h:100
#9 0x00002aaaaaf3e699 in
_Destroy<log4cxx::helpers::ObjectPtrT<log4cxx::Appender> >
(this=0x2aaaac000de0,
__in_chrg=<value optimized out>, __vtt_parm=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:107
#10 __destroy_aux<log4cxx::helpers::ObjectPtrT<log4cxx::Appender>*>
(this=0x2aaaac000de0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:122
#11 _Destroy<log4cxx::helpers::ObjectPtrT<log4cxx::Appender>*>
(this=0x2aaaac000de0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:155
#12 _Destroy<log4cxx::helpers::ObjectPtrT<log4cxx::Appender>*,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > (
this=0x2aaaac000de0, __in_chrg=<value optimized out>, __vtt_parm=<value
optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:182
#13 ~vector (this=0x2aaaac000de0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:272
#14 log4cxx::helpers::AppenderAttachableImpl::~AppenderAttachableImpl
(this=0x2aaaac000de0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at
../../../src/main/include/log4cxx/helpers/appenderattachableimpl.h:46
#15 0x00002aaaaaf8ecfc in ~ObjectPtrT (this=0x61c000, __vtt_parm=<value
optimized out>, __in_chrg=<value optimized out>)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#16 log4cxx::Logger::~Logger (this=0x61c000, __vtt_parm=<value optimized
out>, __in_chrg=<value optimized out>) at logger.cpp:55
#17 0x00002aaaaafc2521 in log4cxx::spi::RootLogger::~RootLogger
(this=0x613b40, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at
../../../src/main/include/log4cxx/spi/rootlogger.h:37
#18 0x00002aaaaaf96a6c in ~ObjectPtrT (this=0x619c58, __in_chrg=<value
optimized out>)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#19 log4cxx::logstream_base::~logstream_base (this=0x619c58,
__in_chrg=<value optimized out>) at logstream.cpp:51
Could someone help?
--
View this message in context: http://old.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p29167682.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in
ObjectPtrBase
Posted by Jade2k <ja...@hotmail.com>.
BTW here is also the stack when one of the exceptions mentioned above is
thrown:
terminate called after throwing an instance of
'log4cxx::helpers::MutexException'
what(): Mutex exception: stat = 1
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x41401940 (LWP 18319)]
0x000000387c630265 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x000000387c630265 in raise () from /lib64/libc.so.6
#1 0x000000387c631d10 in abort () from /lib64/libc.so.6
#2 0x00000038822becb4 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib64/libstdc++.so.6
#3 0x00000038822bcdb6 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00000038822bcde3 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x00000038822bceca in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0x00002aaaaafd3e9d in log4cxx::helpers::synchronized::~synchronized
(this=<value optimized out>,
__in_chrg=<value optimized out>) at synchronized.cpp:46
#7 0x00002aaaaaf7745c in log4cxx::Hierarchy::isDisabled (this=0x61bf40,
level=10000) at hierarchy.cpp:267
#8 0x00002aaaaaf8ca1f in log4cxx::Logger::isEnabledFor (this=0x61e080,
level1=...) at logger.cpp:287
#9 0x00002aaaaaf97079 in log4cxx::logstream_base::logstream_base
(this=0x61bd08, log=<value optimized out>, lvl=...)
at logstream.cpp:47
#10 0x00002aaaaaf97379 in log4cxx::logstream::logstream (this=0x478b,
logger=..., level=...) at logstream.cpp:181
#11 0x0000000000402d2e in myLog::myLog (this=0x61bd08) at mylog.cpp:12
There might be several things going wrong since the behavior differs between
the different throws and the segmentation fault.
--
View this message in context: http://old.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p29167958.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in
ObjectPtrBase
Posted by Jade2k <ja...@hotmail.com>.
Curt Arnold-3 wrote:
>
> Any specific instructions on reproducing the problem would be appreciated.
> Especially along the lines of
>
> 1. fire up this AMI on Amazon Web Services
> 2. Do this and that
> 3. Crash
>
> Setting up non-default development platforms is a chore and having a
> reproducible error makes things easier.
>
Hi Curt,
I don't have AMI. Sorry. So basically I wrote a simple multi-thread
application that just writes to this logger (I was regression testing it)
where each of the thread (2 threads) writes to the same logger. I was using
the logstream (I really prefer the C++ syntax of ostream) as you can
probably guess from the stack.
Now the odd thing is, for the cases of when it throws exceptions, the crash
happens in the beginning. And for the case where it SIGSEGV, it happens
near the end as the ~logstream_base is called.
You'll see the differences when you see the two stack traces I provided.
Did I cover all your questions? If not, ask away.
Cheers,
Jade
--
View this message in context: http://old.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p29184581.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in
ObjectPtrBase
Posted by Jade2k <ja...@hotmail.com>.
Hi Curt,
I was reading your
http://www.opensubscriber.com/message/log4cxx-user@logging.apache.org/4931122.html
post here and I think I understand what I might have done wrong to make it
non-threadsafe (I too had made my logstream a data member). So here's the
modification of my code (though it still seems to either throw an exception
or crash at the end):
In my header file I have this:
class myLog {
public:
~myLog() {}
// data member
log4cxx::LoggerPtr rootLogger;
protected:
// only singleton (friend) will access this
myLog(); // don't need arguments; configuration file does that
private:
// no copy ctor
myLog(const myLog &other);
// no assignment
myLog &operator=(const myLog &other);
friend class ACE_Singleton<myLog, ACE_Null_Mutex>;
};
typedef ACE_Singleton<myLog, ACE_Null_Mutex> LogSingleton;
#define MYLOG_FATAL
log4cxx::logstream(LogSingleton::instance()->rootLogger,
log4cxx::Level::getFatal())
#define MYLOG_ERROR
log4cxx::logstream(LogSingleton::instance()->rootLogger,
log4cxx::Level::getError())
#define MYLOG_WARN
log4cxx::logstream(LogSingleton::instance()->rootLogger,
log4cxx::Level::getWarn())
#define MYLOG_INFO
log4cxx::logstream(LogSingleton::instance()->rootLogger,
log4cxx::Level::getInfo())
#define MYLOG_TRACE
log4cxx::logstream(LogSingleton::instance()->rootLogger,
log4cxx::Level::getTrace())
#define MYLOG_DEBUG
log4cxx::logstream(LogSingleton::instance()->rootLogger,
log4cxx::Level::getDebug())
#define MYLOG_ENDL LOG4CXX_ENDMSG
In the corresponding cpp file I have:
using namespace std;
using namespace log4cxx;
using namespace log4cxx::xml;
using namespace log4cxx::helpers;
myLog::myLog():rootLogger(Logger::getRootLogger()) {
// get configuration file for initial settings
try {
// Load configure file
DOMConfigurator::configure("test.xml");
}
catch (...) {
std::cerr<<"Log4cxx initialization Error: "<<endl;
abort();
}
}
Now this is the routine that I run in my threads:
virtual int svc(void) {
MYLOG_INFO << "I'm in the thread with name=" << name << MYLOG_ENDL;
MYLOG_DEBUG << "And the \"this\" of this class is located at " << hex <<
this
<< dec << MYLOG_ENDL;
// initialized random # generator
srand(count);
while (!shutdown) {
unsigned int tmp=rand_r(&count);
if (tmp%2==0) {
MYLOG_ERROR << "All w0rk and nO pLAy mAkeS "
<< name << " A duLl gIrl" << MYLOG_ENDL;
}
else {
MYLOG_INFO << tmp << " bottles of beer on the wall ..." <<
MYLOG_ENDL;
}
}
return 0;
}
Now once I made logstream no longer a data member, I no longer get the
collisions that I saw earlier. But I'm still observing a variation of
exception/Segmentation run time behavior each time I run the application:
1. The stack when it throws a Mutex exception as it exits:
[Thread 0x41401940 (LWP 7829) exited]
[Thread 0x40a00940 (LWP 7828) exited]
terminate called after throwing an instance of
'log4cxx::helpers::MutexException'
what(): Mutex exception: stat = 22
Program received signal SIGABRT, Aborted.
0x000000387c630265 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x000000387c630265 in raise () from /lib64/libc.so.6
#1 0x000000387c631d10 in abort () from /lib64/libc.so.6
#2 0x00000038822becb4 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib64/libstdc++.so.6
#3 0x00000038822bcdb6 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00000038822bcde3 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x00000038822bceca in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0x00002aaaaafd3f8d in log4cxx::helpers::synchronized::synchronized
(this=<value optimized out>, mutex1=<value optimized out>) at
synchronized.cpp:35
#7 0x00002aaaaafe783d in log4cxx::WriterAppender::close (this=0x628110) at
writerappender.cpp:135
#8 0x00002aaaaaf6d369 in log4cxx::FileAppender::~FileAppender (this=0x1e91,
__in_chrg=<value optimized out>, __vtt_parm=<value optimized out>)
at fileappender.cpp:88
#9 0x00002aaaaaf3e3f8 in
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>::~ObjectPtrT (this=0x61e010,
__in_chrg=<value optimized out>)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#10 0x00002aaaaaf3e699 in
_Destroy<log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > (this=0x61e040,
__in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:107
#11 __destroy_aux<log4cxx::helpers::ObjectPtrT<log4cxx::Appender>*>
(this=0x61e040, __in_chrg=<value optimized out>, __vtt_parm=<value optimized
out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:122
#12 _Destroy<log4cxx::helpers::ObjectPtrT<log4cxx::Appender>*>
(this=0x61e040, __in_chrg=<value optimized out>, __vtt_parm=<value optimized
out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:155
#13 _Destroy<log4cxx::helpers::ObjectPtrT<log4cxx::Appender>*,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > (this=0x61e040,
__in_chrg=<value optimized out>, __vtt_parm=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:182
#14 ~vector (this=0x61e040, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:272
#15 log4cxx::helpers::AppenderAttachableImpl::~AppenderAttachableImpl
(this=0x61e040, __in_chrg=<value optimized out>, __vtt_parm=<value optimized
out>)
at ../../../src/main/include/log4cxx/helpers/appenderattachableimpl.h:46
#16 0x00002aaaaaf8ecfc in ~ObjectPtrT (this=0x61be10, __vtt_parm=<value
optimized out>, __in_chrg=<value optimized out>)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#17 log4cxx::Logger::~Logger (this=0x61be10, __vtt_parm=<value optimized
out>, __in_chrg=<value optimized out>) at logger.cpp:55
#18 0x00002aaaaafc2521 in log4cxx::spi::RootLogger::~RootLogger
(this=0x1e91, __in_chrg=<value optimized out>, __vtt_parm=<value optimized
out>)
at ../../../src/main/include/log4cxx/spi/rootlogger.h:37
#19 0x0000000000403b48 in ~ObjectPtrT (this=0x619c50, __in_chrg=<value
optimized out>) at /usr/local/include/log4cxx/helpers/objectptr.h:100
#20 ~myLog (this=0x619c50, __in_chrg=<value optimized out>) at mylog.h:11
#21 ACE_Singleton<myLog, ACE_Null_Mutex>::~ACE_Singleton (this=0x619c50,
__in_chrg=<value optimized out>) at
/home/zcasilum/ACE_wrappers/ace/Singleton.h:80
#22 0x0000000000403642 in ACE_Singleton<myLog, ACE_Null_Mutex>::cleanup
(this=0x619c50) at /home/zcasilum/ACE_wrappers/ace/Singleton.cpp:112
#23 0x00002aaaaab76b60 in ACE_OS_Exit_Info::call_hooks (this=<value
optimized out>) at ../../ace/Cleanup.cpp:166
#24 0x00002aaaaabbd4a4 in ACE_Object_Manager::fini (this=0x60a6f0) at
../../ace/Object_Manager.cpp:726
#25 0x00002aaaaabbd6b8 in ACE_Object_Manager::~ACE_Object_Manager
(this=0x1e91, __in_chrg=<value optimized out>) at
../../ace/Object_Manager.cpp:417
#26 0x00002aaaaabbd863 in
ACE_Object_Manager_Manager::~ACE_Object_Manager_Manager (this=<value
optimized out>, __in_chrg=<value optimized out>)
at ../../ace/Object_Manager.cpp:882
#27 0x000000387c63368e in __cxa_finalize () from /lib64/libc.so.6
#28 0x00002aaaaab5b636 in __do_global_dtors_aux () from
/usr/local/lib/libACE-5.8.so
#29 0x0000000000000000 in ?? ()
2. The stack when it crashes as it's running and NOT as the executable
exits:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40a00940 (LWP 7927)]
0x00002aaaaaf8ca1c in log4cxx::Logger::isEnabledFor (this=0x2aaaac000940,
level1=...) at logger.cpp:287
287 if(repository == 0 ||
repository->isDisabled(level1->toInt()))
(gdb) where
#0 0x00002aaaaaf8ca1c in log4cxx::Logger::isEnabledFor
(this=0x2aaaac000940, level1=...) at logger.cpp:287
#1 0x00002aaaaaf97079 in log4cxx::logstream_base::logstream_base
(this=0x409ff790, log=<value optimized out>, lvl=...) at logstream.cpp:47
#2 0x00002aaaaaf97349 in log4cxx::logstream::logstream (this=0x61bd00,
logger=..., level=...) at logstream.cpp:181
#3 0x0000000000403bfd in handler::svc (this=0x7fffffffe3b0) at
threadtest.cpp:24
#4 0x00002aaaaac02017 in ACE_Task_Base::svc_run (args=<value optimized
out>) at ../../ace/Task.cpp:275
#5 0x00002aaaaac02f95 in ACE_Thread_Adapter::invoke (this=0x611610) at
../../ace/Thread_Adapter.cpp:98
#6 0x000000387d20673d in start_thread () from /lib64/libpthread.so.0
#7 0x000000387c6d3d1d in clone () from /lib64/libc.so.6
So that line 24 in the handler::svc is
MYLOG_INFO << "I'm in the thread with name=" << name << MYLOG_ENDL;
So do you know what I'm doing wrong here? Why the variation of
exception/segmentation fault behavior?
Just so you know what the patch I had put in as advised at the top of this
thread, I replaced ObjectPtrBase::exchange with the following code:
void* ObjectPtrBase::exchange(void** destination, void* newValue) {
#if _WIN32 && (!defined(_MSC_VER) || _MSC_VER >= 1300)
return InterlockedExchangePointer(destination, newValue);
#elif APR_SIZEOF_VOIDP == 4
return (void*) apr_atomic_xchg32((volatile apr_uint32_t*) destination,
(apr_uint32_t) newValue);
#else
void* oldValue = *destination;
*destination = newValue;
return oldValue;
apr_atomic_xchgptr((volatile void**)destination, newValue);
#endif
}
And built it with the CFLAGS="-fPIC" option. So where am I going wrong
here?
Thanks!
Jade
--
View this message in context: http://old.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p29221033.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in ObjectPtrBase
Posted by Curt Arnold <ca...@apache.org>.
I may have an afternoon free this weekend and see if I can't regain my train of thought.
There has been a tension between wanting to avoid memory leaks on shutdown to not offend Valgrind, Purify et al and not shutting down APR while it is still being used. There were many previous discussion and I can't remember exactly where we left it, but should default to a safe but potentially leaky with an option for leak free but not always safe on shutdown.
Any specific instructions on reproducing the problem would be appreciated. Especially along the lines of
1. fire up this AMI on Amazon Web Services
2. Do this and that
3. Crash
Setting up non-default development platforms is a chore and having a reproducible error makes things easier.
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in
ObjectPtrBase
Posted by Jade2k <ja...@hotmail.com>.
deepak singh-4 wrote:
>
> Use apr, apr-util, expat, log4cxx libraries compiled with -fPIC flag.
> It works in my case.
>> I'l try to fire up a copy of CentOS 5 x64 this weekend.
>>
>> Did it occur during the unit tests or one of the sample applications, or
>> in
>> some other context?
>>
>
I had rewritten a multi-threaded application to test the threadsafetyness of
the log4cxx and got that error. But after rebuilding it with the CFLAGS
option you suggested, the error went away. But I did notice that after
building the log4cxx library, and did a 'make check', it seem to have failed
some of the tests:
SUCCESS
domtestcase : SUCCESS
xmllayouttest : SUCCESS
xmllayouttestcase : SUCCESS
Failed Tests Total Fail Failed %
===================================================
minimumtestcase 2 1 50.00%
patternlayouttest 14 2 14.29%
make[3]: *** [run-unittest] Error 1
Scrolling back to the test printout:
syslogwritertest : -log4cxx: Cannot get information about host:
unknown.invalid
log4cxx: Could not find unknown.invalid. All logging will FAIL.
log4cxx: Cannot get information about host: unknown.invalid
SUCCESS
timezonetestcase : SUCCESS
transcodertestcase : SUCCESS
hierarchytest : SUCCESS
hierarchythresholdtestcase: SUCCESS
l7dtestcase : SUCCESS
leveltestcase : SUCCESS
loggertestcase : -log4cxx: No appender could be found for logger (x).
log4cxx: Please initialize the log4cxx system properly.
SUCCESS
minimumtestcase : |Files [output/filtered] and [witness/ttcc] differ on
line 1
One reads: [14 Jul 2010 16:22:41,470 [main] FATAL ERR - Message 0].
Other reads:[ [main] FATAL ERR - Message 0].
--------------------------------
Contents of output/filtered:
1 : 14 Jul 2010 16:22:41,470 [main] FATAL ERR - Message 0
2 : 14 Jul 2010 16:22:41,470 [main] ERROR ERR - Message 1
3 : 14 Jul 2010 16:22:41,470 [main] FATAL INF - Message 2
4 : 14 Jul 2010 16:22:41,470 [main] ERROR INF - Message 3
5 : 14 Jul 2010 16:22:41,470 [main] WARN INF - Message 4
6 : 14 Jul 2010 16:22:41,470 [main] INFO INF - Message 5
7 : 14 Jul 2010 16:22:41,470 [main] FATAL INF.UNDEF - Message 6
8 : 14 Jul 2010 16:22:41,470 [main] ERROR INF.UNDEF - Message 7
9 : 14 Jul 2010 16:22:41,470 [main] WARN INF.UNDEF - Message 8
10 : 14 Jul 2010 16:22:41,470 [main] INFO INF.UNDEF - Message 9
11 : 14 Jul 2010 16:22:41,470 [main] FATAL INF.ERR - Message 10
12 : 14 Jul 2010 16:22:41,470 [main] ERROR INF.ERR - Message 11
13 : 14 Jul 2010 16:22:41,470 [main] FATAL INF.ERR.UNDEF - Message 12
14 : 14 Jul 2010 16:22:41,470 [main] ERROR INF.ERR.UNDEF - Message 13
15 : 14 Jul 2010 16:22:41,470 [main] FATAL DEB - Message 14
16 : 14 Jul 2010 16:22:41,470 [main] ERROR DEB - Message 15
17 : 14 Jul 2010 16:22:41,470 [main] WARN DEB - Message 16
18 : 14 Jul 2010 16:22:41,470 [main] INFO DEB - Message 17
19 : 14 Jul 2010 16:22:41,470 [main] DEBUG DEB - Message 18
20 : 14 Jul 2010 16:22:41,470 [main] FATAL UNDEF - Message 19
21 : 14 Jul 2010 16:22:41,470 [main] ERROR UNDEF - Message 20
22 : 14 Jul 2010 16:22:41,470 [main] WARN UNDEF - Message 21
23 : 14 Jul 2010 16:22:41,470 [main] INFO UNDEF - Message 22
24 : 14 Jul 2010 16:22:41,470 [main] DEBUG UNDEF - Message 23
25 : 14 Jul 2010 16:22:41,470 [main] INFO INF - Messages should bear
numbers 0 through 23.
--------------------------------
Contents of witness/ttcc:
1 : [main] FATAL ERR - Message 0
2 : [main] ERROR ERR - Message 1
3 : [main] FATAL INF - Message 2
4 : [main] ERROR INF - Message 3
5 : [main] WARN INF - Message 4
6 : [main] INFO INF - Message 5
7 : [main] FATAL INF.UNDEF - Message 6
8 : [main] ERROR INF.UNDEF - Message 7
9 : [main] WARN INF.UNDEF - Message 8
10 : [main] INFO INF.UNDEF - Message 9
11 : [main] FATAL INF.ERR - Message 10
12 : [main] ERROR INF.ERR - Message 11
13 : [main] FATAL INF.ERR.UNDEF - Message 12
14 : [main] ERROR INF.ERR.UNDEF - Message 13
15 : [main] FATAL DEB - Message 14
16 : [main] ERROR DEB - Message 15
17 : [main] WARN DEB - Message 16
18 : [main] INFO DEB - Message 17
19 : [main] DEBUG DEB - Message 18
20 : [main] FATAL UNDEF - Message 19
21 : [main] ERROR UNDEF - Message 20
22 : [main] WARN UNDEF - Message 21
23 : [main] INFO UNDEF - Message 22
24 : [main] DEBUG UNDEF - Message 23
25 : [main] INFO INF - Messages should bear numbers 0 through 23.
\Line 112: Compare::compare(FILTERED, witness) was expected to be true, was
false.
FAILED 1 of 2
Contents of witness/patternLayout.5:
1 : [main] DEBUG atternLayoutTest - Message 0
2 : [main] DEBUG root - Message 0
3 : [main] INFO atternLayoutTest - Message 1
4 : [main] INFO root - Message 1
5 : [main] WARN atternLayoutTest - Message 2
6 : [main] WARN root - Message 2
7 : [main] ERROR atternLayoutTest - Message 3
8 : [main] ERROR root - Message 3
9 : [main] FATAL atternLayoutTest - Message 4
10 : [main] FATAL root - Message 4
-Line 217: Compare::compare(FILTERED,
LOG4CXX_FILE("witness/patternLayout.5")) was expected to be true, was false.
FAILED 2 of 14
propertyconfiguratortest: SUCCESS
I downloaded apache-log4cxx-0.10.0.tar.gz and built it on a 64 bit on a Red
Hat Enterprise Linux Server release 5.5 (Tikanga). Anyone know why the
check is failing?
--
View this message in context: http://old.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p29166444.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.