logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: log4cxx v0.10.0 crash in CharsetDecoder
Date Tue, 19 Jun 2007 15:50:24 GMT

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.


Mime
View raw message