Release build seg faults at vector.push_back above certain size, b

[Guest]

hi everyone.

i'm currently experiencing a strange problem under vc++ 2005 express. i hope
someone has a hint for me, i'm kind of lost atm.

i'm using a vectors of pointers in my code.
using the release build i can add and remove elements aslong as i stay below
a certain vector size (13 in this case, no joke). as soon as the vector tries
to add element 14 i get a runtime error.

the whole thing get's really strange when i use the debug build. i can add
as much elements as i want without any problems (tried above 500). but that's
not all. it works with the debug build aslong as i start from the IDE or if i
doubleclick the debug.exe. it will crash with the same error as the release
build when i start it from a cmd prompt (just one push_back earlier)

i have no clue what to do now. i can't debug cause the debug build works.
inserting some debug msgs show that vector.push_back() seems to trigger the
crash...

suggestions more than welcome

 

[Severian]

hi everyone.

i'm currently experiencing a strange problem under vc++ 2005 express. i hope
someone has a hint for me, i'm kind of lost atm.

i'm using a vectors of pointers in my code.
using the release build i can add and remove elements aslong as i stay below
a certain vector size (13 in this case, no joke). as soon as the vector tries
to add element 14 i get a runtime error.

the whole thing get's really strange when i use the debug build. i can add
as much elements as i want without any problems (tried above 500). but that's
not all. it works with the debug build aslong as i start from the IDE or if i
doubleclick the debug.exe. it will crash with the same error as the release
build when i start it from a cmd prompt (just one push_back earlier)

i have no clue what to do now. i can't debug cause the debug build works.
inserting some debug msgs show that vector.push_back() seems to trigger the
crash...

suggestions more than welcome

Running a debugger introduces extra data and code pages into your
process. So while the debugger is active, you're probably overwriting
some non-critical debug information, or reading some debug info or
code using invalid pointers.

My initial guess is that you're releasing a pointer while it's still
part of a vector and it's being reaccessed later.

To help during the build, set the warning level to 4 (/W4) and define
STRING (-DSTRICT) to detect some coding errors. Do not ignore any
warning unless you understand *exactly* why it can be ignored.

For running (debug or not), be sure all run-time checks are enabled.

Two other things that may help:

1) ero any pointer after you release it:

delete[] ptr;
ptr = NULL;

2) When declaring pointers, always initialize them to null:

OBJECT *ptr = NULL;

Good luck!

 

[Guest]

hi sev,

thx for your suggestions.

Running a debugger introduces extra data and code pages into your
process. So while the debugger is active, you're probably overwriting
some non-critical debug information, or reading some debug info or
code using invalid pointers.

ok, that explains why it works in debug mode.

My initial guess is that you're releasing a pointer while it's still
part of a vector and it's being reaccessed later.

i do remove elements from the vector if some conditions are met. but the
error even occurs if i add more than 13 items to the vector _before_ anything
is removed. no changes are made to the vector but adding items.

the (pseudo) code that adds a pointer to the vector:

funtion addObject()
{
ClassA *ptr = NULL;
ptr = new ClassA;

ptr->someFunction();

vector.push_back( ptr );

ptr = NULL;
}

i don't know what could be going wrong with this code.
is it possible that the push_back() fails with more than x elements because
it's trying to access memory i f**d up with some buggy code earlier?

 

[Larry Brasfield]

....

funtion addObject()
{
ClassA *ptr = NULL;
ptr = new ClassA;

ptr->someFunction();

vector.push_back( ptr );

ptr = NULL;
}

i don't know what could be going wrong with this code.

That code is fine, at least insofar as it is shown.
(Anything could happen during that member call.)

is it possible that the push_back() fails with more than x elements because
it's trying to access memory i f**d up with some buggy code earlier?

That is highly possible. Whenever you see
behavioral changes under circumstance that
should not change the behavior, you should
be thinking "Oh oh, undefined behavior!
Where have I clobbered something that
should have been left alone, used an object
not properly intialized, or abused the heap?"

You should consider yourself fortunate that
the problem shows up while debugging
rather than only when not debugging.

 

[Guest]

i didn't find the particular error yet, but by taking out some of the
routines that might corrupt the heap i got back to normal behaviour.

thx for your help guys.