On May 9, 2007, at 5:46 AM, Rayapudi Sandeep-mgb376 wrote:
Hi,
I am using log4cxx (0.10.0 version) on RHEL 2.6 version. I built it
with apr-1.2.8, apr-util-1.2.8.
When I used that in my application it crashed with backtrace
pointing to memcpy in stdc++ libraray.
************************
(gdb) set args start
(gdb) r
Starting program: /vobs/S3/code/sbin/SysControlCLI start
[Thread debugging using libthread_db enabled]
[New Thread -1209981248 (LWP 9310)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209981248 (LWP 9310)]
0x00b8d09c in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x00b8d09c in memcpy () from /lib/tls/libc.so.6
#1 0x00ab5079 in std::string::_M_mutate () from /usr/lib/libstdc+
+.so.5
#2 0xb7f69863 in std::transform<__gnu_cxx::__normal_iterator<char
const*, std::string>, std::insert_iterator<std::string>, int (*)
(int)> (__first={_M_current = 0x80573ec "XMLLayout"}, __result=
{<std::iterator<std::output_iterator_tag,void,void,void,void>> =
{<No data fields>}, container = 0xbffff4cc, iter = {_M_current =
0x304c2c "xm"}}, __unary_op=0xb444a0 <tolower>) at basic_string.h:1360
#3 0xb7f69426 in log4cxx::helpers::StringHelper::toLowerCase
([EMAIL PROTECTED]) at basic_string.h:474
#4 0xb7ede6e4 in log4cxx::helpers::Class::registerClass
([EMAIL PROTECTED]) at new_allocator.h:62
#5 0xb7ee101a in
log4cxx::helpers::ClassRegistration::ClassRegistration () at
namepatternconverter.cpp:33
#6 0xb7f7c0eb in log4cxx::xml::XMLLayout::registerClass () at
xmllayout.cpp:35
#7 0xb7f7d222 in global constructors keyed to
_ZNK7log4cxx3xml9XMLLayout8getClassEv () at xmllayout.cpp:35
#8 0xb7f7ee05 in __do_global_ctors_aux () from /vobs/S3/tools/
log4cxx-0.10.0/src/.libs/liblog4cxx.so.10
#9 0xb7eccf05 in _init () from /vobs/S3/tools/log4cxx-0.10.0/
src/.libs/liblog4cxx.so.10
#10 0x00b12208 in _dl_init_internal () from /lib/ld-linux.so.2
#11 0x00b067f5 in _dl_start_user () from /lib/ld-linux.so.2
(gdb) q
The program is running. Exit anyway? (y or n) y
******************************
And I have following libraries
[EMAIL PROTECTED]:/usr/lib [\>] ls -l /usr/lib/libstdc++*
-rwxr-xr-x 1 root root 258288 Dec 14 2004 /usr/lib/libstdc++-2-
libc6.1-1-2.9.0.so*
-rwxr-xr-x 1 root root 268428 Dec 14 2004 /usr/lib/libstdc++-3-
libc6.2-2-2.10.0.so*
lrwxrwxrwx 1 root root 30 Feb 20 16:20 /usr/lib/libstdc++-
libc6.1-1.so.2 -> libstdc++-2-libc6.1-1-2.9.0.so*
lrwxrwxrwx 1 root root 31 Feb 20 16:20 /usr/lib/libstdc++-
libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so*
lrwxrwxrwx 1 root root 18 Feb 20 15:29 /usr/lib/libstdc++.so.5
-> libstdc++.so.5.0.7*
-rwxr-xr-x 1 root root 744136 Dec 1 2004 /usr/lib/libstdc++.so.
5.0.7*
lrwxrwxrwx 1 root root 18 Feb 20 15:17 /usr/lib/libstdc++.so.6
-> libstdc++.so.6.0.3*
-rwxr-xr-x 1 root root 806176 Dec 14 2004 /usr/lib/libstdc++.so.
6.0.3*
********************************
Trivial (trivial.cpp) seems to execute to properly.
Can anyone help me out?
Thnx,
Sandeep
Strange. The stack trace suggests that it occurs during static
initialization, so I would assume any log4cxx using app would fail
even trivial.cpp. The stack trace is a little corrupted since it
says that ClassRegistration::ClassRegistration() is in
namepatternconverter.cpp when it is in classregistration.cpp.
If you built using make, did you do "make check" and did those tests
pass?
Does your app fail on start up or are you somehow reloading or
reinitializing log4cxx during the run?
Can you run valgrind on your app and see if it reports anything
suspicious?
