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.
