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

Discussion in 'C++' started by e2point@yahoo.com, Aug 14, 2008.

  1. Guest

    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.
    , Aug 14, 2008
    #1
    1. Advertising

  2. anon Guest

    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
    anon, Aug 14, 2008
    #2
    1. Advertising

  3. Stefan Naewe Guest

    On 8/14/2008 12:28 PM, 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.


    You have an error at line 42

    S.
    --
    Stefan Naewe stefan dot naewe at atlas-elektronik dot com
    Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
    Plain text mails only, please http://www.expita.com/nomime.html
    Stefan Naewe, Aug 14, 2008
    #3
  4. Stefan Naewe Guest

    On 8/14/2008 12:33 PM, anon wrote:
    > 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.

    S.
    --
    Stefan Naewe stefan dot naewe at atlas-elektronik dot com
    Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
    Plain text mails only, please http://www.expita.com/nomime.html
    Stefan Naewe, Aug 14, 2008
    #4
  5. anon Guest

    Stefan Naewe wrote:
    > On 8/14/2008 12:33 PM, anon wrote:
    >> 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.
    anon, Aug 14, 2008
    #5
  6. Guest

    On Aug 14, 4:29 pm, anon <> wrote:
    > Stefan Naewe wrote:
    > > On 8/14/2008 12:33 PM, anon wrote:
    > >> 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
    std::basic_string<char,std::char_traits<char>,std::allocator<char>
    >::_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.
    , Aug 14, 2008
    #6
  7. peter koch Guest

    On 14 Aug., 12:28, 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
    peter koch, Aug 14, 2008
    #7
  8. Guest

    On Aug 14, 6:32 pm, peter koch <> wrote:
    > On 14 Aug., 12:28, 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::eek: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::eek: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
    , Aug 15, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?ZHdlbndhQGNvbXBhbnlhYmMuY29t?=

    Re: Index Out of Bounds Error

    =?Utf-8?B?ZHdlbndhQGNvbXBhbnlhYmMuY29t?=, Oct 20, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    490
    =?Utf-8?B?ZHdlbndhQGNvbXBhbnlhYmMuY29t?=
    Oct 20, 2004
  2. Biff
    Replies:
    4
    Views:
    1,906
    E. Robert Tisdale
    Jan 31, 2005
  3. Replies:
    8
    Views:
    1,913
    Csaba
    Feb 18, 2006
  4. Replies:
    0
    Views:
    395
  5. Rune Allnor
    Replies:
    2
    Views:
    416
    James Kanze
    Nov 21, 2008
Loading...

Share This Page