logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anand Sherkhane" <anan...@gmail.com>
Subject Re: log4cxx v0.10.0 crash in CharsetDecoder
Date Thu, 28 Jun 2007 06:27:47 GMT
On 6/19/07, Curt Arnold <carnold@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.

Mime
View raw message