Address 0xc00a9553 out of bounds inside stl::vector class

[e2point]

hi,
i got a program that is suppose to run 24x7x365. However after
functioning for around 15 minutes, it crashes due to a segmentation
fault. program is written in c++ and runs in RH Linux 4. When
inspected one of the parameters of the crashing frame, i get the
following output.

NOTE : c1 is a std::vector

(gdb) pvector c1
elem[0]: $1 = {
static npos = 4294967295,
_M_dataplus = {
<std::allocator<char>> = {
<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
members of

::_Alloc_hider:

_M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
}
}

...... and more elements like this ....

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.

 

[anon]

hi,
i got a program that is suppose to run 24x7x365. However after
functioning for around 15 minutes, it crashes due to a segmentation
fault. program is written in c++ and runs in RH Linux 4. When
inspected one of the parameters of the crashing frame, i get the
following output.

NOTE : c1 is a std::vector

(gdb) pvector c1
elem[0]: $1 = {
static npos = 4294967295,
_M_dataplus = {
<std::allocator<char>> = {
<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
members of

::_Alloc_hider:

_M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
}
}

..... and more elements like this ....

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.

Instead of accessing the vector elements with the operator[], use at()
method, and you will be able to easier find where is the problem.
Otherwise use something like valgrind to determine cause

 

[Stefan Naewe]

hi,
i got a program that is suppose to run 24x7x365. However after
functioning for around 15 minutes, it crashes due to a segmentation
fault. program is written in c++ and runs in RH Linux 4. When
inspected one of the parameters of the crashing frame, i get the
following output.

NOTE : c1 is a std::vector

(gdb) pvector c1
elem[0]: $1 = {
static npos = 4294967295,
_M_dataplus = {
<std::allocator<char>> = {
<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
members of

::_Alloc_hider:

_M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
}
}

..... and more elements like this ....

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.

You have an error at line 42

S.

 

[Stefan Naewe]

hi,
i got a program that is suppose to run 24x7x365. However after
functioning for around 15 minutes, it crashes due to a segmentation
fault. program is written in c++ and runs in RH Linux 4. When
inspected one of the parameters of the crashing frame, i get the
following output.

NOTE : c1 is a std::vector

(gdb) pvector c1
elem[0]: $1 = {
static npos = 4294967295,
_M_dataplus = {
<std::allocator<char>> = {
<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
members of

::_Alloc_hider:

_M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
}
}

..... and more elements like this ....

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.

Instead of accessing the vector elements with the operator[], use at()
method, and you will be able to easier find where is the problem.
Otherwise use something like valgrind to determine cause

I'd rather suggest following this

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8
to get a sensible answer.

S.

 

[anon]

hi,
i got a program that is suppose to run 24x7x365. However after
functioning for around 15 minutes, it crashes due to a segmentation
fault. program is written in c++ and runs in RH Linux 4. When
inspected one of the parameters of the crashing frame, i get the
following output.

NOTE : c1 is a std::vector

(gdb) pvector c1
elem[0]: $1 = {
static npos = 4294967295,
_M_dataplus = {
<std::allocator<char>> = {
<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
members of
std::basic_string<char,std::char_traits<char>,std::allocator<char>
::_Alloc_hider:
_M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
}
}

..... and more elements like this ....

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.

Instead of accessing the vector elements with the operator[], use at()
method, and you will be able to easier find where is the problem.
Otherwise use something like valgrind to determine cause

I'd rather suggest following this

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8
to get a sensible answer.

Well... You are right, but I just gave him few useful advices regarding
the subject, as I see no questions in his post.

 

[e2point]

(e-mail address removed) wrote:
hi,
i got a program that is suppose to run 24x7x365. However after
functioning for around 15 minutes, it crashes due to a segmentation
fault. program is written in c++ and runs in RH Linux 4. When
inspected one of the parameters of the crashing frame, i get the
following output.
NOTE : c1 is a std::vector
(gdb) pvector c1
elem[0]: $1 = {
  static npos = 4294967295,
  _M_dataplus = {
    <std::allocator<char>> = {
      <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
    members of
std::basic_string<char,std::char_traits<char>,std::allocator<char>
::_Alloc_hider:
    _M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
  }
}
..... and more elements like this ....
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.
Instead of accessing the vector elements with the operator[], use at()
method, and you will be able to easier find where is the problem.
Otherwise use something like valgrind to determine cause

I'd rather suggest following this

   http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8
to get a sensible answer.

Well... You are right, but I just gave him few useful advices regarding
the subject, as I see no questions in his post.

OK, sorry if the post is not clear.

(gdb) pvector c1
elem[0]: $1 = {
static npos = 4294967295,
_M_dataplus = {
<std::allocator<char>> = {
<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
members of

::_Alloc_hider:

_M_p = 0xc00a9553 <Address 0xc00a9553 out of bounds>
}

}

the above is a part of the output i got when i inspected a std::vector
variable in gdb. As can be seen, _M_p member is not in an accessible
memory location.
And i think this is a result of a memory corruption, but wondering
whether this can happen to any other reason than a memory corruption.

 

[peter koch]

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

 

[e2point]

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:perator<<=(cdrStream&) (seqTemplatedecls.h:
168)
==10032== by 0x8195649:
_0RL_cd_5DD34BCFA8420D37_11000000::unmarshalArguments(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:mniOrbPOA::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