types containing vectors or maps

Discussion in 'C++' started by roberts.noah@gmail.com, Feb 16, 2006.

  1. Guest

    It is my understanding that if you contain vectors or maps you don't
    need to create copy constructors because the default calls that
    constructor. It is my understanding that if you use these types you
    don't have to worry about them at all...even if the contents of your
    map or vector may contain other maps or vectors. Am I mistaken in any
    way?

    We are running into a very strange bug that is avoiding detection by
    hiding in the default allocator of std::vector. The crash occurs when
    push_back reaches a point where it actually deletes the current vector
    after creating the new one. None of the types contained within the
    vector contain pointers they manage (there are std containers in one of
    the eventual contents). Luckily this bug also doesn't happen if the
    program is started in the debugger.
     
    , Feb 16, 2006
    #1
    1. Advertising

  2. Kai-Uwe Bux Guest

    wrote:

    > It is my understanding that if you contain vectors or maps you don't
    > need to create copy constructors because the default calls that
    > constructor.


    You mean: if you *only* contain vectors or maps.

    > It is my understanding that if you use these types you
    > don't have to worry about them at all...even if the contents of your
    > map or vector may contain other maps or vectors. Am I mistaken in any
    > way?


    Well, if your maps and vectors contain (by any level of indirection)
    pointers of unknown origin, life gets harder.


    > We are running into a very strange bug that is avoiding detection by
    > hiding in the default allocator of std::vector. The crash occurs when
    > push_back reaches a point where it actually deletes the current vector
    > after creating the new one. None of the types contained within the
    > vector contain pointers they manage (there are std containers in one of
    > the eventual contents).


    Just a wild speculation: maybe you keep an iterator that gets invalidated in
    the reallocation of the vector. That could be an iterator to the vector
    itself or to any container indirectly stored therein.

    Do you have code you could post that shows the problem?


    > Luckily this bug also doesn't happen if the program is started in the
    > debugger.


    "Luckily"?



    Good luck.

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Feb 16, 2006
    #2
    1. Advertising

  3. Daniel T. Guest

    In article <>,
    wrote:

    > It is my understanding that if you contain vectors or maps you don't
    > need to create copy constructors because the default calls that
    > constructor. It is my understanding that if you use these types you
    > don't have to worry about them at all...even if the contents of your
    > map or vector may contain other maps or vectors. Am I mistaken in any
    > way?


    Right, as long as you don't have any of them holding pointers they will
    take care of everything for you.

    > We are running into a very strange bug that is avoiding detection by
    > hiding in the default allocator of std::vector. The crash occurs when
    > push_back reaches a point where it actually deletes the current vector
    > after creating the new one. None of the types contained within the
    > vector contain pointers they manage (there are std containers in one of
    > the eventual contents). Luckily this bug also doesn't happen if the
    > program is started in the debugger.


    You have a memory overwrite somewhere in your code, you are going to
    have to go through it by eye and find out where an invalid pointer is
    being dereferenced. IMPORTANT: the bug probably is *not* in the code
    that crashes, or anywhere near it.

    --
    Magic depends on tradition and belief. It does not welcome observation,
    nor does it profit by experiment. On the other hand, science is based
    on experience; it is open to correction by observation and experiment.
     
    Daniel T., Feb 16, 2006
    #3
  4. Guest

    Kai-Uwe Bux wrote:
    > wrote:
    >
    > > It is my understanding that if you contain vectors or maps you don't
    > > need to create copy constructors because the default calls that
    > > constructor.

    >
    > You mean: if you *only* contain vectors or maps.


    Well, no, there are also primatives.
    >
    > > It is my understanding that if you use these types you
    > > don't have to worry about them at all...even if the contents of your
    > > map or vector may contain other maps or vectors. Am I mistaken in any
    > > way?

    >
    > Well, if your maps and vectors contain (by any level of indirection)
    > pointers of unknown origin, life gets harder.
    >
    >
    > > We are running into a very strange bug that is avoiding detection by
    > > hiding in the default allocator of std::vector. The crash occurs when
    > > push_back reaches a point where it actually deletes the current vector
    > > after creating the new one. None of the types contained within the
    > > vector contain pointers they manage (there are std containers in one of
    > > the eventual contents).

    >
    > Just a wild speculation: maybe you keep an iterator that gets invalidated in
    > the reallocation of the vector. That could be an iterator to the vector
    > itself or to any container indirectly stored therein.


    I don't believe so. Nothing obvious anyway.
    >
    > Do you have code you could post that shows the problem?


    No, program is huge and proprietery and like Daniel said, it could be
    anywhere; I really think something out there is hosing a buffer
    somewhere and this vector is always in the way...which is odd
    but...well I have no idea. I wasn't really expecting to be able to be
    helped ;) Only if I was wrong about the above and I was damn sure I
    wasn't but there was some discussion about it.
    >
    >
    > > Luckily this bug also doesn't happen if the program is started in the
    > > debugger.

    >
    > "Luckily"?


    Yeah, nice huh...We'll just tell the customers they have to run the
    program in the debugger...yeah, that should work ;)

    I don't envy my coworker :p
     
    , Feb 16, 2006
    #4
  5. Jeff Flinn Guest

    wrote:
    > Kai-Uwe Bux wrote:
    >> wrote:
    >>


    ....

    >>> Luckily this bug also doesn't happen if the program is started in
    >>> the debugger.

    >>
    >> "Luckily"?

    >
    > Yeah, nice huh...We'll just tell the customers they have to run the
    > program in the debugger...yeah, that should work ;)
    >
    > I don't envy my coworker :p


    Perhaps your compiler is initializing memory when under debug, but not when
    compiling optimized. I know MSVC allows this to be modified for debug builds
    and/or allows generation of debug info for release/optimized builds. You may
    be able to track down the problem in either of these modes.

    Jeff Flinn
     
    Jeff Flinn, Feb 16, 2006
    #5
  6. Guest

    Jeff Flinn wrote:
    > wrote:
    > > Kai-Uwe Bux wrote:
    > >> wrote:
    > >>

    >
    > ...
    >
    > >>> Luckily this bug also doesn't happen if the program is started in
    > >>> the debugger.
    > >>
    > >> "Luckily"?

    > >
    > > Yeah, nice huh...We'll just tell the customers they have to run the
    > > program in the debugger...yeah, that should work ;)
    > >
    > > I don't envy my coworker :p

    >
    > Perhaps your compiler is initializing memory when under debug, but not when
    > compiling optimized. I know MSVC allows this to be modified for debug builds
    > and/or allows generation of debug info for release/optimized builds. You may
    > be able to track down the problem in either of these modes.


    It was definately a buffer overrun. Heap corruption caused by someone
    doing something like:

    char * p = new char[strlen(x) + y];
    char * p2 = new char[strlen(p) + y];

    Don't ask me why that was in there...obviously a typo of some sort but
    the way the guy found it was by using this:
    http://support.microsoft.com/?id=286470
     
    , Feb 16, 2006
    #6
    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. Fred Ma
    Replies:
    15
    Views:
    640
    Fred Ma
    Jan 30, 2004
  2. Simon Elliott
    Replies:
    4
    Views:
    1,173
    Simon Elliott
    Mar 10, 2005
  3. Sheep
    Replies:
    1
    Views:
    397
    Sheep
    Aug 14, 2006
  4. Marcus
    Replies:
    2
    Views:
    597
    Marcus
    Dec 9, 2005
  5. Replies:
    3
    Views:
    709
    Shadowman
    Mar 26, 2008
Loading...

Share This Page