«

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.

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

In article < .com>,
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.

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

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

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 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
>
> 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