Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / March 2005

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
whocares - 16 Mar 2005 17:15 GMT
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 - 16 Mar 2005 18:34 GMT
>hi everyone.
>
[quoted text clipped - 17 lines]
>
>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!

--
Sev
whocares - 16 Mar 2005 20:01 GMT
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 - 16 Mar 2005 22:07 GMT
...
> funtion addObject()
> {
[quoted text clipped - 9 lines]
>
> 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.

Signature

--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.

whocares - 16 Mar 2005 23:51 GMT
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.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.