This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: STL memory management


On Sat, Aug 17, 2013 at 6:04 PM, Hatt Tom <net.study.sea@gmail.com> wrote:
>
> here is my example:
> int main()
> {
>      vector<int>  myvec;
>      int  a[3];
>
>     a[4] = 90;
>     myvec.push_back(30);
> }
>
> As you can see ,access to the array a is over rang, is maybe destroy
> myvec's data ,
> My question is  : will  the next push_back(30) corrupt memory due to this error

Once you go out of bounds, all bets are off, the program's behavior is
undefined.
And this question is kind of off topic for this list, so please take
any followup questions offlist.  (Maybe to your teacher :-)

But since you asked, let's poke it with a stick and see what happens.

On my machine, the slightly longer program

#include <vector>
#include <cstdio>
#include <cstring>

void hexdump(const void *p, int len)
{
    const unsigned char *q = (const unsigned char *)p;
    printf("%p: ", q);
    while (len-- > 0)
        printf("%02x ", *q++);
    printf("\n");
}

int main()
{
    int a[3];
    std::vector<int> myvec;
    int b[3];
    int i;

    printf("myvec is at %p and is %d bytes long\n", &myvec, (int)sizeof(myvec));
    printf("a     is at %p and is %d bytes long\n", &a[0], (int)sizeof(a));
    printf("b     is at %p and is %d bytes long\n", &b[0], (int)sizeof(b));
    hexdump(&myvec, sizeof(myvec));
    for (i=0; i > -9; i--) {
        printf("Overwriting %p\n", &a[i]);
        a[i] = 0x12345678;
        hexdump(&myvec, sizeof(myvec));
        myvec.push_back(30);
    }
}

does this when run under valgrind:

myvec is at 0x7ff000340 and is 24 bytes long
a     is at 0x7ff000360 and is 12 bytes long
b     is at 0x7ff000370 and is 12 bytes long
0x7ff000340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
Overwriting 0x7ff000360
0x7ff000340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
Overwriting 0x7ff00035c
0x7ff000340: 40 a0 a1 05 00 00 00 00 44 a0 a1 05 00 00 00 00 44 a0 a1
05 00 00 00 00
Overwriting 0x7ff000358
0x7ff000340: 90 a0 a1 05 00 00 00 00 98 a0 a1 05 00 00 00 00 98 a0 a1
05 00 00 00 00
Overwriting 0x7ff000354
0x7ff000340: e0 a0 a1 05 00 00 00 00 ec a0 a1 05 00 00 00 00 f0 a0 a1
05 78 56 34 12
Overwriting 0x7ff000350
0x7ff000340: e0 a0 a1 05 00 00 00 00 f0 a0 a1 05 00 00 00 00 78 56 34
12 78 56 34 12
==24828== Invalid write of size 4
==24828==    at 0x400CF2:
__gnu_cxx::new_allocator<int>::construct(int*, int const&) (in
/home/dank/a.out)
==24828==    by 0x400BA9: std::vector<int, std::allocator<int>
>::push_back(int const&) (stl_vector.h:830)
==24828==    by 0x400A98: main (bad.cc:29)

Note how the compiler merrily reordered variables in memory; a and b
are both *after* myvec on the stack.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]