On 6/29/07, Marshall Powers <[EMAIL PROTECTED]> wrote:
I'm getting a segfault on 64-bit AIX 5.3. I'm using static libraries of
log4cxx, apr, and aprutil. Here is a test program and Makefile I am using
that causes the crash:
_*main.cpp*_
#include <log4cxx/logger.h>
#include <log4cxx/basicconfigurator.h>
#include <log4cxx/rolling/rollingfileappender.h>
using namespace log4cxx;
using namespace log4cxx::rolling;
int main(int argc, char * argv[]) {
LoggerPtr root = Logger::getRootLogger();
BasicConfigurator::configure();
RollingFileAppenderPtr rfa;
if(argc > 1) {
rfa = new RollingFileAppender();
}
LOG4CXX_DEBUG(root, "HELLO WORLD!");
return 0;
}
_*Makefile*_
LOG4CXX=/path_to_log4cxx
INCLUDE=-I$(LOG4CXX)/include
LIBDIR=-L$(LOG4CXX)/lib
LIBS=-llog4cxxd -lapr-1d -laprutil-1d -liconv -pthread
FLAGS=-g -maix64
BIN=testptr
$(BIN): main.cpp
g++ $(FLAGS) $(INCLUDE) $(LIBDIR) $(LIBS) main.cpp -o $(BIN)
clean:
rm -f core $(BIN)
run:
./$(BIN)
all: main.cpp
Basically, it does some very basic logging. If you give no command-line
args, the program runs just fine, no trouble. If you pass any arguments, it
will instantiate a RollingFileAppender before doing the logging. However, if
you do create that object, you get a segfault. GDB shows this:
(gdb) set args 1
(gdb) run
Starting program: /home/mpowers/log4cxx_smart/testptr 1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0x09000000000523ec in malloc_y () from /usr/lib/libc.a(shr_64.o)
(gdb) bt
#0 0x09000000000523ec in malloc_y () from /usr/lib/libc.a(shr_64.o)
#1 0x090000000004f478 in malloc_common_52_36 () from
/usr/lib/libc.a(shr_64.o)
#2 0x09000000003d499c in iconv_open (t_name=0x1002a3808 "UTF-8",
f_name=0x9001000a0001108 "ISO8859-1")
at ../../../../../../../src/bos/usr/ccs/lib/libiconv/iconv.c:431
#3 0x000000010005386c in apr_xlate_open (convset=0x1100cec58,
topage=0x1002a3808 "UTF-8", frompage=0x9001000a0001108 "ISO8859-1",
pool=0x1100cec98)
at /home.local/mpowers/new_log4cxx/lib/apr-util-1.2.7
/xlate/xlate.c:251
#4 0x000000010004f93c in
log4cxx::helpers::APRCharsetDecoder::APRCharsetDecoder(char const*)
(this=0x1100cec30, frompage=0x1 "")
at /home.local/mpowers/new_log4cxx/src/charsetdecoder.cpp:64
#5 0x0000000100050168 in
log4cxx::helpers::CharsetDecoder::createDefaultDecoder() () at
/home.local/mpowers/new_log4cxx/src/charsetdecoder.cpp:460
#6 0x0000000100050260 in
log4cxx::helpers::CharsetDecoder::getDefaultDecoder() () at
/home.local/mpowers/new_log4cxx/src/charsetdecoder.cpp:467
#7 0x000000010004d150 in log4cxx::helpers::Transcoder::decode(char
const*, unsigned long, std::string&) (src=0x1100ccbe8 "HELLO WORLD!",
len=12,
[EMAIL PROTECTED]) at
/home.local/mpowers/new_log4cxx/src/transcoder.cpp:57
#8 0x00000001000bf6c4 in void
log4cxx::helpers::Transcoder::decode<std::string>(std::string const&,
std::string&) ([EMAIL PROTECTED],
[EMAIL PROTECTED]) at
/home.local/mpowers/new_log4cxx/include/log4cxx/helpers/transcoder.h:49
#9 0x00000001000c5ac8 in
log4cxx::Logger::forcedLog(log4cxx::helpers::ObjectPtrT<log4cxx::Level>
const&, std::string const&, log4cxx::spi::LocationInfo const&)
(this=0x1100c4a70, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at
/home.local/mpowers/new_log4cxx/src/logger.cpp:109
#10 0x0000000100000ad8 in main (argc=2, argv=0xffffffffffffab8) at
main.cpp:17
This crash seems to occur if I instantiate any object and give it to a
smart pointer (*Ptr) variable. It's not limited to RollingFileAppender. Any
ideas for resolving this problem? Can anyone else reproduce this on their
own AIXes? I've tested this code on other OSes such as HPUX, windows,
solaris, and linux without trouble.
Thanks for the help,
Marshall
Hi,
Looks like you are facing similar problem that I had faced few days back.
But I was on SPARC Solaris. I'm producing the problem statement and its
resolution below.
<snip>
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.
>
On 6/19/07, Curt Arnold <[EMAIL PROTECTED]> wrote:
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.
Anand Sherkhane wrote:
> 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.
</snip>
Please go through the solution mentioned by Curt and if that doesn't work,
I've provided my temporary fix - I bet that's not a solution for you.
