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 Marshall Powers <mp...@appsecinc.com> on 2007/06/28 20:52:53 UTC
AIX segfault
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,
dst=@0xffffffffffff8d8) 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&) (src=@0xffffffffffff9c0,
dst=@0xffffffffffff8d8) 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, level1=@0x1100aa1c0, message=@0xffffffffffff9c0,
location=@0xffffffffffff9a0) 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
Re: AIX segfault
Posted by Anand Sherkhane <an...@gmail.com>.
On 6/29/07, Marshall Powers <mp...@appsecinc.com> 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,
>
> dst=@0xffffffffffff8d8) 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&) (src=@0xffffffffffff9c0,
>
> dst=@0xffffffffffff8d8) 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, level1=@0x1100aa1c0, message=@0xffffffffffff9c0,
> location=@0xffffffffffff9a0) 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 <ca...@apache.org> 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.
RE: AIX segfault
Posted by Marshall Powers <mp...@appsecinc.com>.
Sorry, looks like I jumped the gun and didn't rtfemail completely. I ran
"make check" on aprutil 1.2.8 and did get a segfault, here is the output of
that group of tests:
APR Queue Test
======================
Initializing the context OK
test stats 3 consumers (rate 400/sec) 4 producers (rate 300/sec) queue size
100 sleep 30
Initializing the queue OK
Starting consumers OK
Sleeping
1800 producer intr
1286 producer intr
OK
Terminating queue OK
Waiting for threads to exit
1286 producer: queue terminated APR_EOF
772 consumer:queue terminated APR_EOF
1800 producer: queue terminated APR_EOF
515 consumer:queue terminated APR_EOF
258 consumer:queue terminated APR_EOF
1029 producer: queue terminated APR_EOF
1543 producer: queue terminated APR_EOF
OK
PASS: UTF-8 -> UTF-8
/bin/sh[2]: 1257642 Segmentation fault
Usage: ./dbd driver-name [params]
make[1]: Leaving directory `/home/mpowers/AIX-APR/apr-util-1.2.8/test'
...
Is that where you expected it?
Sorry for the earlier confusion and thank you for your continuing help. I
will post a message about this on the APR mailing list.
Marshall
-----Original Message-----
From: log4cxx-user-return-2061-mpowers=appsecinc.com@logging.apache.org
[mailto:log4cxx-user-return-2061-mpowers=appsecinc.com@logging.apache.org]
On Behalf Of Curt Arnold
Sent: 2007-Jun-29 Fri 4:35 PM
To: Log4CXX User
Subject: Re: AIX segfault
On Jun 29, 2007, at 10:31 AM, Marshall Powers wrote:
>
> I did some research and it looks like ISO8859-1 is another name for
> some
> standard US English encoding. I don't know if this "en_US" is possibly
> causing trouble.
ISO-8859-1 would be a very common encoding for any western european
language (which includes English). See http://en.wikipedia.org/wiki/
Iso-8859-1. On a western european unix, the character set is almost
always going to be US-ASCII, ISO-8859-1 or UTF-8. UTF-8 can encode
all of the Unicode character spec, US-ASCII is the first 128
characters in unicode and ISO-8859-1 is the first 256.
>
> "3) Download the current APR and APR-util and run "make check" on apr-
> util. "
>
> bash-3.00$ make check
> (cd test && make check)
> make[1]: Entering directory `/home/mpowers/AIX-APR/apr-1.2.9/test'
> for prog in testlockperf testmutexscope testall ; do \
> ./$prog; \
> if test $? = 255; then \
> echo "$prog failed"; \
> break; \
> fi; \
> done
Try running "make check" on apr-util and skip "make check" on apr
itself. apr-xlate is in apr-util and the apr-util unit tests should
indirectly call iconv_open.
>
> "4) Would appreciate you keeping the list advised of this one."
>
> Done!
>
>
> Thanks,
> Marshall Powers
>
>
Re: AIX segfault
Posted by Curt Arnold <ca...@apache.org>.
On Jun 29, 2007, at 10:31 AM, Marshall Powers wrote:
>
> I did some research and it looks like ISO8859-1 is another name for
> some
> standard US English encoding. I don't know if this "en_US" is possibly
> causing trouble.
ISO-8859-1 would be a very common encoding for any western european
language (which includes English). See http://en.wikipedia.org/wiki/
Iso-8859-1. On a western european unix, the character set is almost
always going to be US-ASCII, ISO-8859-1 or UTF-8. UTF-8 can encode
all of the Unicode character spec, US-ASCII is the first 128
characters in unicode and ISO-8859-1 is the first 256.
>
> "3) Download the current APR and APR-util and run "make check" on apr-
> util. "
>
> bash-3.00$ make check
> (cd test && make check)
> make[1]: Entering directory `/home/mpowers/AIX-APR/apr-1.2.9/test'
> for prog in testlockperf testmutexscope testall ; do \
> ./$prog; \
> if test $? = 255; then \
> echo "$prog failed"; \
> break; \
> fi; \
> done
Try running "make check" on apr-util and skip "make check" on apr
itself. apr-xlate is in apr-util and the apr-util unit tests should
indirectly call iconv_open.
>
> "4) Would appreciate you keeping the list advised of this one."
>
> Done!
>
>
> Thanks,
> Marshall Powers
>
>
RE: AIX segfault
Posted by Marshall Powers <mp...@appsecinc.com>.
<--snip-->
"The stack trace does look iconv releated, but unlike Anand's, it
doesn't appear that apr_xlate_open is returning null, but that
iconv_open is segfaulting on a request for a ISO8859-1 to UTF-8
transcoder which would seem to be an AIX bug. The "ISO8859-1" would
make it appear like the locale is properly set. I would try the
following:
1) Run locale to see the value of LC_CTYPE, I'm assuming it is ISO8859-1"
bash-3.00$ locale
LANG=en_US
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_MESSAGES="en_US"
LC_ALL=
"2) Run iconv -l to see if ISO8859-1 and UTF-8 appear in list
If ISO8859-1 is not in the iconv -l list but a slightly different
form is set the LC_CTYPE environment variable with ISO-8859-1 or "
whatever
bash-3.00$ iconv -l
...stuff
ISO8859-1
...stuff
UTF-8
...
I did some research and it looks like ISO8859-1 is another name for some
standard US English encoding. I don't know if this "en_US" is possibly
causing trouble.
"3) Download the current APR and APR-util and run "make check" on apr-
util. "
bash-3.00$ make check
(cd test && make check)
make[1]: Entering directory `/home/mpowers/AIX-APR/apr-1.2.9/test'
for prog in testlockperf testmutexscope testall ; do \
./$prog; \
if test $? = 255; then \
echo "$prog failed"; \
break; \
fi; \
done
APR Lock Performance Test
==============
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 1 threads OK
microseconds: 245057 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 1 threads OK
microseconds: 254207 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 1 threads OK
microseconds: 392831 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 2 threads OK
microseconds: 972323 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 2 threads OK
microseconds: 812852 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 2 threads OK
microseconds: 3088038 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 3 threads OK
microseconds: 2002213 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 3 threads OK
microseconds: 1972974 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 3 threads OK
microseconds: 12508983 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 4 threads OK
microseconds: 2919378 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 4 threads OK
microseconds: 2919410 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 4 threads OK
microseconds: 29074112 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 5 threads OK
microseconds: 3033266 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 5 threads OK
microseconds: 2899733 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 5 threads OK
microseconds: 37269300 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 6 threads OK
microseconds: 3262061 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 6 threads OK
microseconds: 3502135 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 6 threads OK
microseconds: 47357268 usec
Trying proc mutexes with mechanism `default'...
Mutex mechanism `default' is global in scope on this platform.
Trying global mutexes with mechanism `default'...
no problems encountered...
Trying proc mutexes with mechanism `sysvsem'...
Mutex mechanism `sysvsem' is global in scope on this platform.
Trying global mutexes with mechanism `sysvsem'...
no problems encountered...
Trying proc mutexes with mechanism `posix'...
Mutex mechanism `posix' is global in scope on this platform.
Trying global mutexes with mechanism `posix'...
no problems encountered...
Trying proc mutexes with mechanism `fcntl'...
Mutex mechanism `fcntl' is not global in scope on this platform.
Trying global mutexes with mechanism `fcntl'...
no problems encountered...
Trying proc mutexes with mechanism `proc_pthread'...
Mutex mechanism `proc_pthread' is global in scope on this platform.
Trying global mutexes with mechanism `proc_pthread'...
no problems encountered...
testatomic : SUCCESS
testdir : SUCCESS
testdso : SUCCESS
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : SUCCESS
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : SUCCESS
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : SUCCESS
testnames : SUCCESS
testoc : SUCCESS
testpath : SUCCESS
testpipe : SUCCESS
testpoll : |
At this point, testpoll hangs. Any advice for how to remove that group of
unit tests perhaps, so we can find one that exposes this bug?
"4) Would appreciate you keeping the list advised of this one."
Done!
Thanks,
Marshall Powers
RE: AIX segfault
Posted by Marshall Powers <mp...@appsecinc.com>.
I noticed that the program was crashing in iconv_open("UTF-8", "ISO8859-1").
Out of curiosity, I tried calling that function from my own program, before
"new RollingFileAppender()", to see if it was purely a problem with my IBM
iconv. The segfault vanished. Here is a revised program:
_main.cpp_
#include <log4cxx/logger.h>
#include <log4cxx/basicconfigurator.h>
#include <log4cxx/rolling/rollingfileappender.h>
#include <iconv.h>
using namespace log4cxx;
using namespace log4cxx::rolling;
int main(int argc, char * argv[]) {
LoggerPtr root = Logger::getRootLogger();
BasicConfigurator::configure();
RollingFileAppenderPtr rfa;
iconv_t cd = iconv_open("UTF-8", "ISO8859-1");
if(argc > 1) {
rfa = new RollingFileAppender();
if(argc > 3)
{
iconv_open("UTF-8", "ISO8859-1");
}
if(argc > 2)
{
rfa = new RollingFileAppender();
}
}
LOG4CXX_DEBUG(root, "HELLO WORLD!");
return 0;
}
And here is an example of what happens when I run it:
bash-3.00$ ./testptr
60 [0x1] DEBUG root null - HELLO WORLD!
bash-3.00$ ./testptr 1
2 [0x1] DEBUG root null - HELLO WORLD!
bash-3.00$ ./testptr 1 2
Segmentation fault
bash-3.00$ ./testptr 1 2 4
2 [0x1] DEBUG root null - HELLO WORLD!
Note how in the case of argc == 3 (two arguments) there is a second call to
new RollingFileAppender() without a preceding call to iconv_open, and the
segfault returns. I have tried this with other strings for iconv_open, and
it appears that the arguments must be "UTF-8" and "ISO8859-1" in order to
prevent the segfault.
I don't know if that helps diagnose the problem, but it seemed interesting.
Thanks for your help,
Marshall
Re: AIX segfault
Posted by Curt Arnold <ca...@apache.org>.
On Jun 28, 2007, at 1:52 PM, Marshall Powers wrote:
> (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,
>
> dst=@0xffffffffffff8d8) 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&) (src=@0xffffffffffff9c0,
>
> dst=@0xffffffffffff8d8) 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,
> level1=@0x1100aa1c0, message=@0xffffffffffff9c0,
> location=@0xffffffffffff9a0) 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
>
>
The stack trace does look iconv releated, but unlike Anand's, it
doesn't appear that apr_xlate_open is returning null, but that
iconv_open is segfaulting on a request for a ISO8859-1 to UTF-8
transcoder which would seem to be an AIX bug. The "ISO8859-1" would
make it appear like the locale is properly set. I would try the
following:
Run locale to see the value of LC_CTYPE, I'm assuming it is ISO8859-1
Run iconv -l to see if ISO8859-1 and UTF-8 appear in list
If ISO8859-1 is not in the iconv -l list but a slightly different
form is set the LC_CTYPE environment variable with ISO-8859-1 or
whatever
If UTF-8 isn't but a different form is used, you could hack
charsetdecoder and charsetencoder to use the other form of UTF-8.
Please let the list know if this one happens.
Download the current APR and APR-util and run "make check" on apr-
util. I'd assume you'd get the same segfault, however now you could
report it to the apr-dev mailing list where you'd be more likely to
get support by someone with an AIX box and more knowledge of the
platform.
Would appreciate you keeping the list advised of this one.