On Aug 14, 6:32*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 14 Aug., 12:28, e2po...@yahoo.com wrote:
hi,
according to this out put, _M_p member is not accessible because
address 0xc00a9553 is out of bounds, and the only reason i can think
of is a memory corruption. Is there any other reason for this to
happen.
It likely is a memory corruption, but could also be accessing (1) the
memory-location of an object that has ceased to exist or by (2)
accessing something as an object that never was:
(1)
int* x = new int;
delete x;
*x = 1;
(2)
int* x
*x = 1;
Other stuff could provoke this error as well, but these are the most
likely, IMHO.
/Peter
Hi,
thanks for the reply.
Yas i agree with you, but i think i can assume that this kind of
errors are not present in the code because i had a through look in to
the code to see anything like that is present. This forces me to
consider this to be a memory corruption.
To find the corrupting place, i ran the binary under valgrind memcheck
tool. This slows down the process by almost 100, and after a long time
(2 days of continuous operation), i got an error from valgrind saiying
some memory allocation has failed. here is it:
**10032** new/new[] failed and should throw an exception, but Valgrind
cannot throw exceptions and so is aborting instead. Sorry.
==10032== at 0x4004631: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==10032== by 0x4005148: operator new[](unsigned)
(vg_replace_malloc.c:268)
==10032== by 0x8197F1B:
_CORBA_Sequence_Octet::operator<<=(cdrStream&) (seqTemplatedecls.h:
168)
==10032== by 0x8195649:
_0RL_cd_5DD34BCFA8420D37_11000000::unmarshalArgume nts(cdrStream&)
(documentmessages.h:123)
==10032== by 0x40EDD4E:
omni::GIOP_S::ReceiveRequest(omniCallDescriptor&) (in /ld/work/c10728/
esp/lib/libomniORB4.so.0.7)
==10032== by 0x40CD50F: omniCallHandle::upcall(omniServant*,
omniCallDescriptor&) (in /ld/work/c10728/esp/lib/libomniORB4.so.0.7)
==10032== by 0x8192A49:
interfaces::alertinginternal::_impl_ae_sessions::_ dispatch(omniCallHandle&)
(alertinginternalstub.cpp:1393)
==10032== by 0x40BCAF5: omni::omniOrbPOA::dispatch(omniCallHandle&,
omniLocalIdentity*) (in /ld/work/c10728/esp/lib/libomniORB4.so.0.7)
==10032== by 0x40A028C:
omniLocalIdentity::dispatch(omniCallHandle&) (in /ld/work/c10728/esp/
lib/libomniORB4.so.0.7)
==10032== by 0x40ED210: omni::GIOP_S::handleRequest() (in /ld/work/
c10728/esp/lib/libomniORB4.so.0.7)
==10032== by 0x40ED0B6: omni::GIOP_S::dispatcher() (in /ld/work/
c10728/esp/lib/libomniORB4.so.0.7)
==10032== by 0x40E9DD1: omni::giopWorker::real_execute() (in /ld/
work/c10728/esp/lib/libomniORB4.so.0.7)
==10032==
==10032== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 180174
from 4)
==10032== malloc/free: in use at exit: 460,635,839 bytes in 22,318,880
blocks.
==10032== malloc/free: 2,011,424,148 allocs, 1,989,105,267 frees,
142,332,360,008 bytes allocated.
==10032== For a detailed leak analysis, rerun with: --leak-check=yes
==10032== For counts of detected errors, rerun with: -v
the machine this has run had ebough of memory and im certain that the
program does not have huge memory leaks. So im not sure why the 'new'
operator has failed. Can it be a problem with valgrind it self?
Can you recommend me a good memory corruption detection tool for Linux
other than valgrind? im OK to recompile/re-link.
I've already tried NJAMD and electric fence but was not that helpful.
its enough if it can detect memory overflows.
Thanks