-----Original Message-----
From: John Reiser [mailto:[email protected]]
Sent: Thu 4/21/2011 3:07 PM
To: [email protected]
Subject: Re: [Valgrind-users] Valgrind errors with log4cxx
On 04/20/2011 03:43 PM, Chatterjee, Shash wrote:
John,
Good question, the locally built libs were to replicate a particular legacy
build :-). I have now removed locally built zlib as well. Valgrind still seg
faults, see below.
Thanks,
Shash
[schatterjee@dal-schatter-l ESM]$ ldd ./test | grep / | grep '=>' |
while read lib arrow file addr; do rpm -qf $file; done | sort -u
apr-1.3.9-3.fc13.i686
apr-util-1.3.10-1.fc14.i686
cyrus-sasl-lib-2.1.23-12.fc14.i686
db4-4.8.30-2.fc14.i686
expat-2.0.1-10.fc13.i686
glibc-2.13-1.i686
libgcc-4.5.1-4.fc14.i686
libstdc++-4.5.1-4.fc14.i686
libuuid-2.18-4.8.fc14.i686
log4cxx-0.10.0-9.fc13.i686
nspr-4.8.7-1.fc14.i686
nss-3.12.9-9.fc14.i686
nss-softokn-freebl-3.12.9-5.fc14.i686
nss-util-3.12.9-1.fc14.i686
openldap-2.4.23-4.fc14.i686
zlib-1.2.5-2.fc14.i686
[schatterjee@dal-schatter-l ESM]$ !va
valgrind ./test
==6822== Memcheck, a memory error detector
==6822== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==6822== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==6822== Command: ./test
==6822==
==6822== Conditional jump or move depends on uninitialised value(s)
==6822== at 0x4005453: operator delete[](void*, std::nothrow_t const&)
(vg_replace_malloc.c:421)
==6822== by 0x512DCE7: ??? (in /usr/lib/libstdc++.so.6.0.14)
==6822== by 0x509D7C8: std::underflow_error::underflow_error(std::string
const&) (stdexcept.cc:72)
==6822== by 0x509DFAD: virtual thunk to std::strstream::~strstream() (in
/usr/lib/libstdc++.so.6.0.14)
==6822== by 0x4DE9AD: pthread_once (pthread_once.S:122)
==6822== by 0x509E0A8: std::locale::locale() (strstream.cc:369)
==6822== by 0x509AF97: std::ios_base::Init::Init() (locale_facets.h:1930)
==6822== by 0x410E115: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x4167CFC: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x40B393B: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x3348FB: call_init (dl-init.c:68)
==6822== by 0x334A18: _dl_init (dl-init.c:132)
==6822==
==6822== Invalid free() / delete / delete[]
==6822== at 0x4005493: operator delete[](void*, std::nothrow_t const&)
(vg_replace_malloc.c:421)
==6822== by 0x512DCE7: ??? (in /usr/lib/libstdc++.so.6.0.14)
==6822== by 0x509D7C8: std::underflow_error::underflow_error(std::string
const&) (stdexcept.cc:72)
==6822== by 0x509DFAD: virtual thunk to std::strstream::~strstream() (in
/usr/lib/libstdc++.so.6.0.14)
==6822== by 0x4DE9AD: pthread_once (pthread_once.S:122)
==6822== by 0x509E0A8: std::locale::locale() (strstream.cc:369)
==6822== by 0x509AF97: std::ios_base::Init::Init() (locale_facets.h:1930)
==6822== by 0x410E115: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x4167CFC: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x40B393B: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x3348FB: call_init (dl-init.c:68)
==6822== by 0x334A18: _dl_init (dl-init.c:132)
==6822== Address 0x5059b24 is not stack'd, malloc'd or (recently) free'd
==6822==
==6822== Use of uninitialised value of size 4
==6822== at 0x40054A2: operator delete[](void*, std::nothrow_t const&)
(vg_replace_malloc.c:421)
==6822== by 0x509D7C8: std::underflow_error::underflow_error(std::string
const&) (stdexcept.cc:72)
==6822== by 0x509DFAD: virtual thunk to std::strstream::~strstream() (in
/usr/lib/libstdc++.so.6.0.14)
==6822== by 0x4DE9AD: pthread_once (pthread_once.S:122)
==6822== by 0x509E0A8: std::locale::locale() (strstream.cc:369)
==6822== by 0x509AF97: std::ios_base::Init::Init() (locale_facets.h:1930)
==6822== by 0x410E115: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x4167CFC: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x40B393B: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x3348FB: call_init (dl-init.c:68)
==6822== by 0x334A18: _dl_init (dl-init.c:132)
==6822== by 0x3268AE: ??? (in /lib/ld-2.13.so)
==6822==
vex x86->IR: unhandled instruction bytes: 0xEA 0xB5 0x8 0x5
==6822== Invalid read of size 1
==6822== at 0x512DCE8: ??? (in /usr/lib/libstdc++.so.6.0.14)
==6822== by 0x509D7C8: std::underflow_error::underflow_error(std::string
const&) (stdexcept.cc:72)
==6822== by 0x509DFAD: virtual thunk to std::strstream::~strstream() (in
/usr/lib/libstdc++.so.6.0.14)
==6822== by 0x4DE9AD: pthread_once (pthread_once.S:122)
==6822== by 0x509E0A8: std::locale::locale() (strstream.cc:369)
==6822== by 0x509AF97: std::ios_base::Init::Init() (locale_facets.h:1930)
==6822== by 0x410E115: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x4167CFC: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x40B393B: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x3348FB: call_init (dl-init.c:68)
==6822== by 0x334A18: _dl_init (dl-init.c:132)
==6822== by 0x3268AE: ??? (in /lib/ld-2.13.so)
==6822== Address 0x6a050f16 is not stack'd, malloc'd or (recently) free'd
==6822==
==6822==
==6822== Process terminating with default action of signal 11 (SIGSEGV)
==6822== Access not within mapped region at address 0x6A050F16
==6822== at 0x512DCE8: ??? (in /usr/lib/libstdc++.so.6.0.14)
==6822== by 0x509D7C8: std::underflow_error::underflow_error(std::string
const&) (stdexcept.cc:72)
==6822== by 0x509DFAD: virtual thunk to std::strstream::~strstream() (in
/usr/lib/libstdc++.so.6.0.14)
==6822== by 0x4DE9AD: pthread_once (pthread_once.S:122)
==6822== by 0x509E0A8: std::locale::locale() (strstream.cc:369)
==6822== by 0x509AF97: std::ios_base::Init::Init() (locale_facets.h:1930)
==6822== by 0x410E115: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x4167CFC: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x40B393B: ??? (in /usr/lib/liblog4cxx.so.10.0.0)
==6822== by 0x3348FB: call_init (dl-init.c:68)
==6822== by 0x334A18: _dl_init (dl-init.c:132)
==6822== by 0x3268AE: ??? (in /lib/ld-2.13.so)
==6822== If you believe this happened as a result of a stack
==6822== overflow in your program's main thread (unlikely but
==6822== possible), you can try to increase the size of the
==6822== main thread stack using the --main-stacksize= flag.
==6822== The main thread stack size used in this run was 8388608.
==6822==
==6822== HEAP SUMMARY:
==6822== in use at exit: 3,416 bytes in 107 blocks
==6822== total heap usage: 452 allocs, 346 frees, 11,471 bytes allocated
==6822==
==6822== LEAK SUMMARY:
==6822== definitely lost: 0 bytes in 0 blocks
==6822== indirectly lost: 0 bytes in 0 blocks
==6822== possibly lost: 1,624 bytes in 53 blocks
==6822== still reachable: 1,792 bytes in 54 blocks
==6822== suppressed: 0 bytes in 0 blocks
==6822== Rerun with --leak-check=full to see details of leaked memory
==6822==
==6822== For counts of detected and suppressed errors, rerun with: -v
==6822== Use --track-origins=yes to see where uninitialised values come from
==6822== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 40 from 8)
Segmentation fault (core dumped)
[schatterjee@dal-schatter-l ESM]$
> I deleted my locally built log4cxx, apt and apt-util from /usr/local/lib,
> and reinstalled using yum. Now the ldd list is bigger and more like yours,
> except for differences like gcc-4.5.1 versus 4.6, etc.
How well does "valgrind ./test" work now?
[And why are you using a locally-build zlib instead of
zlib-1.2.5-2.fc14.i686.rpm ?]
--
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
