VS.Net screwing up

Started by
30 comments, last by Shag 21 years, 1 month ago
Anyone else had a problem with VS.Net bailing out? It happens to me EVERYTIME i allocate large amounts of memory, when run within the IDE. Large amounts = about 100Mb or more. I''m deallocating properly. There are no bugs. It just comes up with the dialog saying that there is a problem with ''your'' program. Do you wish to restart the IDE? The .Net IDE is far better than the previous versions, make no mistake ... but this is getting really anoying. Anyone in a similar boat? Regards
Advertisement
you''re not using malloc() or new to allocate a 100MB block of memory, are you?

But... but that''s what HITLER would say!!
yes ... malloc ... but i don''t know the exact amount i want till a run an test.
That''s really not a good idea. malloc() is best suited for smaller allocations. Call win32 API functions directly rather than using the CRT.

And if you''re still having problems, debug and find out exactly what''s going on. Is malloc (or whatever) returning an error? is the pointer valid? are you going out of bounds? It''s a poor workman that blames his tools.

But... but that''s what HITLER would say!!
That''s the point ... there are no erros ... the code is fine ... it''s just that VS.Net (when you exit) causes problems. BTW - I''ve done this to be portable - no specific API calls.

Besides, the malloc() calls the WIN32 memory allocators - the various HEAPALLOC calls.

Why should this cause the VS IDE to bomb out????

Regards
Let me say again - this code is so simple it''s difficult to make mistakes! My program is just fine, but the IDE/Windows is doing something strange here!
PS - I take afront at your suggestion that ''it''s a poor workman ...''
Sorry for the affront... GameDev has more than its share of newbies saying "VS.NET SAYZ I HAVE A SYNTXA ERROR BUT I DONT...IT SUX0RZ". It becomes kind of a kneejerk reaction.

Does this happen with both debug and release builds? I''m betting that only debug builds will cause this (when the debug heap is used). I would still suggest HeapAlloc; wrapping it in #if..#else..#endif will keep your code platform-independent.

But... but that''s what HITLER would say!!
There lays the problem - it doesn't manifest itself until I try to close down the IDE!

If I allocate a small amount of memory, it's fine. When I allocate a larger amount the IDE fails to close, and causes errors.

For example:

struct STAR
{
float *x *y *z;
etc ...
}

This is an SoA format. (obviously!). I'm going for pure perforamnce. Then do:

x = ( float* ) malloc( sizeof( float ) * 4000000 );
etc...

Close down the IDE, and windows (XP) goes into overdrive! Swapfile HELL!!!! Trust me - I'm doing everything correctly ... all the proper free's etc. I've tried malloc, and _aligned_malloc, with the appropriate _aligned_free() etc. But it happens every time.

This must be a major bug within VS.Net. I wondered who else has had this problem?

I wouldn't mind, apart from the fact that I'm dealing with extremely large datasets all the time!

It's a pain in the arse. I'd love to know what's going on.

Regards

[edited by - Shag on March 15, 2003 12:14:12 AM]
BTW - what's the difference between malloc() and HeapAlloc? Surely malloc calls HeapAlloc()? Or at least an equivalent.

[edited by - Shag on March 15, 2003 12:18:33 AM]

This topic is closed to new replies.

Advertisement