Re: Crash in log4cxx v0.10.0 - forward_iterator_tag

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.