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: AIX segfault
Date Fri, 29 Jun 2007 06:42:16 GMT
On 6/29/07, Marshall Powers <mpowers@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 <carnold@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.

Mime
View raw message