You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Anand Sherkhane <an...@gmail.com> on 2007/06/19 14:58:40 UTC
log4cxx v0.10.0 crash in CharsetDecoder
Hi,
I'm seeing a crash in CharsetDecoder when I execute following statement in a
test program:
Logger::getLogger("test");
Complete stack trace is as follows:
<snip>
ff01e42c _lwp_kill (6, 0, ffbff178, ff088f18, 1, ffbff1e4) + 8
fefb5c60 abort (ff0e1afc, 1bf, ff0ad104, ff088238, 1, ffbfef0d) + 100
ff0e1ac4 _ZN10__cxxabiv111__terminateEPFvvE (fefb5b60, ffbfeba0, 474e5543,
432b2b00, 0, ff1099c8) + 4
ff0e1afc _ZSt9terminatev (0, fefb5b60, ff0e1ae0, ff1099cc, 474e5543,
432b2b00) + 1c
ff0e1c6c __cxa_throw (2d850, ff32cc88, ff2a4fc4, 0, 0, 2024) + 8c
ff2a7dac _ZN7log4cxx7helpers17APRCharsetDecoderC1EPKc (23548, 1, 2d868,
23218, 1, ffbff43c) + 110
ff220e4c _ZN7log4cxx7helpers14CharsetDecoder20createDefaultDecoderEv
(ff292f10, 142, ff2153c8, ff199f4c, 1, ffbff4bc) + 10
ff220e74 _ZN7log4cxx7helpers14CharsetDecoder17getDefaultDecoderEv (ff33db58,
46, ff3840a8, ff19575c, 2, ff33db58) + 4
ff292f10 _ZN7log4cxx7helpers10Transcoder6decodeEPKcjRSs (10f78, 4, ffbff548,
ff33db50, 81010100, ff0000) + f8
ff2552f0 _ZN7log4cxx6Logger9getLoggerEPKc (10f78, ff000000, 3, ffbff5d8,
ff148484, 23528) + 48
</snip>
I'm on a Solaris box, details:
bash-2.05$ uname -a
SunOS 5.9 Generic_112233-07 sun4u sparc SUNW,Ultra-5_10
I think log4cxx is not reaching at a point where it reads the config file
but I produce it here anyways:
<snip>
log4j.rootLogger=root, TEST_EVEN_LOGGER
log4j.appender.TEST_EVEN_LOGGER=org.apache.log4j.RollingFileAppender
log4j.appender.TEST_EVEN_LOGGER.Threshold=debug
log4j.appender.TEST_EVEN_LOGGER.File=mylog.log
log4j.appender.TEST_EVEN_LOGGER.layout=org.apache.log4j.PatternLayout
log4j.appender.TEST_EVEN_LOGGER.layout.ConversionPattern=%d{%d %b %Y
%H:%M:%S} %p %t %c - %m%n
log4j.appender.TEST_EVEN_LOGGER.ImmediateFlush=true
log4j.appender.TEST_EVEN_LOGGER.Append=true
log4j.appender.TEST_EVEN_LOGGER.MaxBackupIndex=5
log4j.appender.TEST_EVEN_LOGGER.MaxFileSize=512KB
</snip>
I read following suggestion somewhere on the web:
change implmentation of CharsetDecoder::getDefaultDecoder() to replace
<snip>
static CharsetDecoderPtr decoder(createDefaultDecoder());
return decoder;
</snip>
with
<snip>
return createDefaultDecoder();
</snip>
I tried, but I still the crash and the same stack trace.
Any pointers? I'm in urgent need.
Thanks and Regards,
Anand.
Re: log4cxx v0.10.0 crash in CharsetDecoder
Posted by Anand Sherkhane <an...@gmail.com>.
On 6/19/07, Curt Arnold <ca...@apache.org> wrote:
>
>
> On Jun 19, 2007, at 7:58 AM, Anand Sherkhane wrote:
>
> > Hi,
> >
> > I'm seeing a crash in CharsetDecoder when I execute following
> > statement in a test program:
> > Logger::getLogger("test");
> >
> > Complete stack trace is as follows:
> > <snip>
> > ff01e42c _lwp_kill (6, 0, ffbff178, ff088f18, 1, ffbff1e4) + 8
> > fefb5c60 abort (ff0e1afc, 1bf, ff0ad104, ff088238, 1, ffbfef0d)
> > + 100
> > ff0e1ac4 _ZN10__cxxabiv111__terminateEPFvvE (fefb5b60, ffbfeba0,
> > 474e5543, 432b2b00, 0, ff1099c8) + 4
> > ff0e1afc _ZSt9terminatev (0, fefb5b60, ff0e1ae0, ff1099cc,
> > 474e5543, 432b2b00) + 1c
> > ff0e1c6c __cxa_throw (2d850, ff32cc88, ff2a4fc4, 0, 0, 2024) + 8c
> > ff2a7dac _ZN7log4cxx7helpers17APRCharsetDecoderC1EPKc (23548, 1,
> > 2d868, 23218, 1, ffbff43c) + 110
> > ff220e4c
> > _ZN7log4cxx7helpers14CharsetDecoder20createDefaultDecoderEv
> > (ff292f10, 142, ff2153c8, ff199f4c, 1, ffbff4bc) + 10
> > ff220e74 _ZN7log4cxx7helpers14CharsetDecoder17getDefaultDecoderEv
> > (ff33db58, 46, ff3840a8, ff19575c, 2, ff33db58) + 4
> > ff292f10 _ZN7log4cxx7helpers10Transcoder6decodeEPKcjRSs (10f78, 4,
> > ffbff548, ff33db50, 81010100, ff0000) + f8
> > ff2552f0 _ZN7log4cxx6Logger9getLoggerEPKc (10f78, ff000000, 3,
> > ffbff5d8, ff148484, 23528) + 48
> > </snip>
> >
> > I'm on a Solaris box, details:
> > bash-2.05$ uname -a
> > SunOS 5.9 Generic_112233-07 sun4u sparc SUNW,Ultra-5_10
> >
> ....
> >
> > I read following suggestion somewhere on the web:
> > change implmentation of CharsetDecoder::getDefaultDecoder() to replace
> > <snip>
> >
> > static CharsetDecoderPtr decoder(createDefaultDecoder());
> > return decoder;
> > </snip>
> >
> > with
> > <snip>
> > return createDefaultDecoder();
> > </snip>
> > I tried, but I still the crash and the same stack trace.
> >
> > Any pointers? I'm in urgent need.
> >
> > Thanks and Regards,
> > Anand.
> >
>
> Your stack trace is likely due to apr_xlate_open returning null in
> APRCharsetDecoder::APRCharsetDecoder which should throws an
> IllegalArgumentException which isn't handled well. It would be
> interesting if you could debug that routine and see what happens
> after the initial failure around line 61. The code that checks for
> "646" was specifically added to avoid the problem for Solaris.
>
> Possible resolutions:
>
> Ensure that setlocale(LC_ALL, "") or setlocale(LC_CTYPE, "") is
> called before any call to Logger::getLogger() to initialize the
> locale based on the current state of environment variables. It can't
> be done within log4cxx since that is a pretty significant side
> effect, see https://issues.apache.org/jira/browse/LOGCXX-167
>
> Attempt "make check" with apr-util. If that fails, see if a later
> version of apr-util fixes the problem. Upgrade log4cxx to use that
> later version of apr_util.
>
> Set LOG4CXX_LOCALE_ENCODING_UTF8, LOG4CXX_LOCALE_ENCODING_ISO_8859_1
> or LOG4CXX_LOCALE_ENCODING_US_ASCII to bypass use of APR decoding.
>
> I made changes as suggested by you(setlocale, apr-util) but I was still
seeing the crash. So I changed CharsetDecoder::createDefaultDecoder() and
CharsetEncoder::createDefaultEncoder() to *always* return
UTF8Charset(De|En)coder.
In my case, since UTF8 support was sufficient, I could make this change.
Re: log4cxx v0.10.0 crash in CharsetDecoder
Posted by Curt Arnold <ca...@apache.org>.
On Jun 19, 2007, at 7:58 AM, Anand Sherkhane wrote:
> Hi,
>
> I'm seeing a crash in CharsetDecoder when I execute following
> statement in a test program:
> Logger::getLogger("test");
>
> Complete stack trace is as follows:
> <snip>
> ff01e42c _lwp_kill (6, 0, ffbff178, ff088f18, 1, ffbff1e4) + 8
> fefb5c60 abort (ff0e1afc, 1bf, ff0ad104, ff088238, 1, ffbfef0d)
> + 100
> ff0e1ac4 _ZN10__cxxabiv111__terminateEPFvvE (fefb5b60, ffbfeba0,
> 474e5543, 432b2b00, 0, ff1099c8) + 4
> ff0e1afc _ZSt9terminatev (0, fefb5b60, ff0e1ae0, ff1099cc,
> 474e5543, 432b2b00) + 1c
> ff0e1c6c __cxa_throw (2d850, ff32cc88, ff2a4fc4, 0, 0, 2024) + 8c
> ff2a7dac _ZN7log4cxx7helpers17APRCharsetDecoderC1EPKc (23548, 1,
> 2d868, 23218, 1, ffbff43c) + 110
> ff220e4c
> _ZN7log4cxx7helpers14CharsetDecoder20createDefaultDecoderEv
> (ff292f10, 142, ff2153c8, ff199f4c, 1, ffbff4bc) + 10
> ff220e74 _ZN7log4cxx7helpers14CharsetDecoder17getDefaultDecoderEv
> (ff33db58, 46, ff3840a8, ff19575c, 2, ff33db58) + 4
> ff292f10 _ZN7log4cxx7helpers10Transcoder6decodeEPKcjRSs (10f78, 4,
> ffbff548, ff33db50, 81010100, ff0000) + f8
> ff2552f0 _ZN7log4cxx6Logger9getLoggerEPKc (10f78, ff000000, 3,
> ffbff5d8, ff148484, 23528) + 48
> </snip>
>
> I'm on a Solaris box, details:
> bash-2.05$ uname -a
> SunOS 5.9 Generic_112233-07 sun4u sparc SUNW,Ultra-5_10
>
....
>
> I read following suggestion somewhere on the web:
> change implmentation of CharsetDecoder::getDefaultDecoder() to replace
> <snip>
>
> static CharsetDecoderPtr decoder(createDefaultDecoder());
> return decoder;
> </snip>
>
> with
> <snip>
> return createDefaultDecoder();
> </snip>
> I tried, but I still the crash and the same stack trace.
>
> Any pointers? I'm in urgent need.
>
> Thanks and Regards,
> Anand.
>
Your stack trace is likely due to apr_xlate_open returning null in
APRCharsetDecoder::APRCharsetDecoder which should throws an
IllegalArgumentException which isn't handled well. It would be
interesting if you could debug that routine and see what happens
after the initial failure around line 61. The code that checks for
"646" was specifically added to avoid the problem for Solaris.
Possible resolutions:
Ensure that setlocale(LC_ALL, "") or setlocale(LC_CTYPE, "") is
called before any call to Logger::getLogger() to initialize the
locale based on the current state of environment variables. It can't
be done within log4cxx since that is a pretty significant side
effect, see https://issues.apache.org/jira/browse/LOGCXX-167
Attempt "make check" with apr-util. If that fails, see if a later
version of apr-util fixes the problem. Upgrade log4cxx to use that
later version of apr_util.
Set LOG4CXX_LOCALE_ENCODING_UTF8, LOG4CXX_LOCALE_ENCODING_ISO_8859_1
or LOG4CXX_LOCALE_ENCODING_US_ASCII to bypass use of APR decoding.