Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in ObjectPtrBase
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 TestsTotal FailFailed % === 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] FAT
Re: log4cxx-0.10.0: Fix for 64 bit-only thread safety bug in ObjectPtrBase
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=0x7fffe0e0, 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=0x7fffe0e0, parent=0x617c68, abort_fn=0,
allocator=0x613b50) at memory/unix/apr_pools.c:252
#1 apr_pool_create_ex (newpool=0x7fffe0e0, parent=0x617c68, abort_fn=0,
allocator=0x613b50) at memory/unix/apr_pools.c:856
#2 0x2afb1060 in log4cxx::helpers::Pool::Pool (this=0x7fffe0e0)
at pool.cpp:34
#3 0x2af67692 in log4cxx::helpers::MutexException::formatMessage
(stat=22) at exception.cpp:227
#4 0x2af67739 in log4cxx::helpers::MutexException::MutexException
(this=0x624750, stat=2090152296) at exception.cpp:213
#5 0x2afd3f77 in log4cxx::helpers::synchronized::synchronized
(this=, mutex1=)
at synchronized.cpp:35
#6 0x2afe783d in log4cxx::WriterAppender::close
(this=0x2c000b20) at writerappender.cpp:135
#7 0x2af6d369 in log4cxx::FileAppender::~FileAppender
(this=0x613b40, __in_chrg=,
__vtt_parm=) at fileappender.cpp:88
#8 0x2af3e3f8 in
log4cxx::helpers::ObjectPtrT::~ObjectPtrT
(this=0x2c000cc0,
__in_chrg=) at
../../../src/main/include/log4cxx/helpers/objectptr.h:100
#9 0x2af3e699 in
_Destroy >
(this=0x2c000de0,
__in_chrg=, __vtt_parm=)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:107
#10 __destroy_aux*>
(this=0x2c000de0, __in_chrg=,
__vtt_parm=)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:122
#11 _Destroy*>
(this=0x2c000de0, __in_chrg=,
__vtt_parm=)
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 > (
this=0x2c000de0, __in_chrg=, __vtt_parm=)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:182
#13 ~vector (this=0x2c000de0, __in_chrg=,
__vtt_parm=)
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=0x2c000de0, __in_chrg=,
__vtt_parm=) at
../../../src/main/include/log4cxx/helpers/appenderattachableimpl.h:46
#15 0x2af8ecfc in ~ObjectPtrT (this=0x61c000, __vtt_parm=, __in_chrg=)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#16 log4cxx::Logger::~Logger (this=0x61c000, __vtt_parm=, __in_chrg=) at logger.cpp:55
#17 0x2afc2521 in log4cxx::spi::RootLogger::~RootLogger
(this=0x613b40, __in_chrg=,
__vtt_parm=) at
../../../src/main/include/log4cxx/spi/rootlogger.h:37
#18 0x2af96a6c in ~ObjectPtrT (this=0x619c58, __in_chrg=)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#19 log4cxx::logstream_base::~logstream_base (this=0x619c58,
__in_chrg=) 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
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)] 0x00387c630265 in raise () from /lib64/libc.so.6 (gdb) where #0 0x00387c630265 in raise () from /lib64/libc.so.6 #1 0x00387c631d10 in abort () from /lib64/libc.so.6 #2 0x0038822becb4 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6 #3 0x0038822bcdb6 in ?? () from /usr/lib64/libstdc++.so.6 #4 0x0038822bcde3 in std::terminate() () from /usr/lib64/libstdc++.so.6 #5 0x0038822bceca in __cxa_throw () from /usr/lib64/libstdc++.so.6 #6 0x2afd3e9d in log4cxx::helpers::synchronized::~synchronized (this=, __in_chrg=) at synchronized.cpp:46 #7 0x2af7745c in log4cxx::Hierarchy::isDisabled (this=0x61bf40, level=1) at hierarchy.cpp:267 #8 0x2af8ca1f in log4cxx::Logger::isEnabledFor (this=0x61e080, level1=...) at logger.cpp:287 #9 0x2af97079 in log4cxx::logstream_base::logstream_base (this=0x61bd08, log=, lvl=...) at logstream.cpp:47 #10 0x2af97379 in log4cxx::logstream::logstream (this=0x478b, logger=..., level=...) at logstream.cpp:181 #11 0x00402d2e 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
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
Hi Curt,
I was reading your
http://www.opensubscriber.com/message/log4cxx-u...@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;
};
typedef ACE_Singleton 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: "<, mutex1=) at
synchronized.cpp:35
#7 0x2afe783d in log4cxx::WriterAppender::close (this=0x628110) at
writerappender.cpp:135
#8 0x2af6d369 in log4cxx::FileAppender::~FileAppender (this=0x1e91,
__in_chrg=, __vtt_parm=)
at fileappender.cpp:88
#9 0x2af3e3f8 in
log4cxx::helpers::ObjectPtrT::~ObjectPtrT (this=0x61e010,
__in_chrg=)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#10 0x2af3e699 in
_Destroy > (this=0x61e040,
__in_chrg=,
__vtt_parm=) at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:107
#11 __destroy_aux*>
(this=0x61e040, __in_chrg=, __vtt_parm=)
at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_construct.h:122
#12 _Destroy*>
(this=0x61e040, __in_chrg=, __vtt_parm=)
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 > (this=0x61e040,
__in_chrg=, __vtt_parm=)
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=,
__vtt_parm=)
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=, __vtt_parm=)
at ../../../src/main/include/log4cxx/helpers/appenderattachableimpl.h:46
#16 0x2af8ecfc in ~ObjectPtrT (this=0x61be10, __vtt_parm=, __in_chrg=)
at ../../../src/main/include/log4cxx/helpers/objectptr.h:100
#17 log4cxx::Logger::~Logger (this=0x61be10, __vtt_parm=, __in_chrg=) at logger.cpp:55
#18 0x2afc2521 in log4cxx::spi::RootLogger::~RootLogger
(this=0x1e91, __in_chrg=, __vtt_parm=)
at ../../../src/main/include/log4cxx/spi/rootlogger.h:37
#19 0x00403b48 in ~ObjectPtrT (this=0x619c50, __in_chrg=) at /usr/local/include/log4cxx/helpers/objectptr.h:100
#20 ~myLog (this=0x619c50, __in_chrg=) at mylog.h:11
#21 ACE_Singleton::~ACE_Singleton (this=0x619c50,
__in_chrg=) at
/home/zcasilum/ACE_wrappers/ace/Singleton.h:80
#22 0x00403642 in ACE_Singleton::cleanup
(this=0x619c50) at /home/zcasilum/ACE_wrappers/ace/Singleton.cpp:112
#23 0x2ab76b60 in ACE_OS_Exit_Info::call_hooks (this=) at ../../ace/Cleanup.cpp:166
#24 0x2abbd4a4 in ACE_Object_Manager::fini (this=0x60a6f0) at
../../ace/Object_Manager.cpp:726
#25 0x2abbd6b8 in ACE_Object_Manager::~ACE_Object_Manager
(this=0x1e91, __in_chrg=) at
../../ace/Object_Manager.cpp:417
#26 0x2abbd863 in
ACE_Object_Manager_Manager::~ACE_Object_Manager_Manager (this=, __in_chrg=)
at ../../ace/Object_Manager.cpp:882
#27 0x00387c63368e in __cxa_finalize () from /lib64/libc.so.6
#28 0x2ab5b636 in __do_global_dtors_aux () from
/usr/local/lib/libACE-5.8.so
#29 0x 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)]
0x2af8ca1c in log4cxx::Logger::isEnabl
