Hi,
Yes, it is possible that 'plainMsg' was NULL.
I checked this behavior in a test program(passed NULL to LogRawMesg) and I
see similar crash.
Thanks for pointing it out.
Regards,
Anand.
On 6/23/07, Curt Arnold <[EMAIL PROTECTED]> wrote:
On Jun 22, 2007, at 12:34 AM, Anand Sherkhane wrote:
Right. So here I produce some more details.
Stack trace with some more info:
<snip>
fee20218 _lwp_kill (6, 0, fa77a410, fee88ef8, 1, fa77a47c) + 8
fedb6e98 abort (feee1afc, 1bf, feead104, fee88248, 1, fa77a1a5) + 100
feee1ac4 _ZN10__cxxabiv111__terminateEPFvvE (7178ac, fa779e38, 474e5543,
432b2b00, 0, fef099c8) + 4
feee1afc _ZSt9terminatev (0, 7178ac, feee1ae0, fef099cc, 474e5543,
432b2b00) + 1c
feee1c6c __cxa_throw (fa0748, fef05614, feed65c4, 0, 1, 34c) + 8c
feeba748 _ZSt19__throw_logic_errorPKc (feee3f98, 1, fa0760, 19089c0,
bd0368, bd0370) + 6c
feedb754 _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag
(0, ffffffff, fa77a7a8, fa77a6f7, 2710, f71bd080) + 5c
feed8a44 _ZNSsC1EPKcRKSaIcE (fa77a7a0, 0, fa77a7a8, 800, fa77a3a0,
fa77a7a8) +
24
fe3a9430 _ZN9ApacheLog10LogRawMesgEiPKc (b641c0, 64, 0, 1bc37f8, fd96eea0,
8000) + 644
f16c8d68 ObAnPluginFn (92bfb8, 13153d0, f41818, fa77ad1c, 7567696e, 9000)
+ 1c3c
</snip>
ApacheLog is a wrapper class and LogRawMesg is a method of that class.
Implementation:
void ApacheLog::LogRawMesg(int level, const char* plainMsg)
{
switch(level) {
case LOGFATAL: LOG4CXX_FATAL(logger, plainMsg ); break;
case LOGINFO: LOG4CXX_INFO(logger, plainMsg ); break;
case LOGWARN: LOG4CXX_WARN(logger, plainMsg ); break;
case LOGERROR: LOG4CXX_ERROR(logger, plainMsg ); break;
case LOGDEBUG: LOG4CXX_DEBUG(logger, plainMsg ); break;
}
}
ApacheLog::logger is a member variable that is initialized in constructor
of ApacheLog using Logger::getLogger()
ApacheLog::LogRawMesg() is called from a shared object.
BTW: I checked if length message size was an issue and it doesn't look
like it is.
Environment details:
OS: Solaris 9(SPARC)
Compiler: g++ 3.3.2
log4cxx v0.10.0
Regards,
Anand.
Any chance that plainMsg is NULL? The LOG4CXX_ macros will eventually
result in a call to
void Logger::forcedLog(const LevelPtr& level, const std::string&
message,
const log4cxx::spi::LocationInfo& location);
which will result in the transparent construction and destruction of a
std::string to contain the message. The std::string constructor would
likely not like a NULL argument and could die with a stack trace something
like you are seeing.
