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.
On 6/21/07, Curt Arnold <[EMAIL PROTECTED]> wrote:
On Jun 21, 2007, at 12:38 AM, Anand Sherkhane wrote:
Hi,
Any updates?
Regards,
Anand.
On 6/20/07, Anand Sherkhane <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm seeing a crash in my app that uses log4cxx v0.10.0. Relevant stack
> trace is produced below:
> <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
> </snip>
>
> Any idea where that points to?
>
> Is it happening because the message being passed to the logger is more
> than it can handle?
>
> By the way: What is the maximum size of message that log4cxx v0.10.0 can
> handle?
>
> Regards,
> Anand.
>
>
Isn't obvious that the stack trace is log4cxx related. Was next line
snipped of the stack trace an identifiable line in your code that was making
a call to log4cxx?
Knowing platform, compiler, et al would be helpful. But without either a
stack trace that clearly identifies a location in log4cxx or a test, there
is not enough to go on.
I don't believe that log4cxx imposes its own limit of message size, so you
are probably limited to available memory or the max size of
std::basic_string.
