Archived

This topic is now archived and is closed to further replies.

Shag

VS.Net screwing up

Recommended Posts

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

Share this post


Link to post
Share on other sites
Sneftel    1788
you''re not using malloc() or new to allocate a 100MB block of memory, are you?


But... but that''s what HITLER would say!!

Share this post


Link to post
Share on other sites
Sneftel    1788
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!!

Share this post


Link to post
Share on other sites
Shag    122
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

Share this post


Link to post
Share on other sites
Shag    122
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!

Share this post


Link to post
Share on other sites
Sneftel    1788
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!!

Share this post


Link to post
Share on other sites
Shag    122
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]

Share this post


Link to post
Share on other sites
Shag    122
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]

Share this post


Link to post
Share on other sites
spock    217
The malloc from Microsoft's CRT calls HeapAlloc more or less directly. For 100 MB blocks, VirtualAlloc is probably a better choice (more efficient), but either of those should work.

[edited by - spock on March 15, 2003 12:37:54 AM]

Share this post


Link to post
Share on other sites
Shag    122
Why a better choice? If both fit into RAM.

EDIT - I can't spell!

[edited by - Shag on March 15, 2003 12:40:07 AM]

Share this post


Link to post
Share on other sites
spock    217
HeapAlloc is better suited for relatively small memory blocks (and it''s a pretty good allocator, at least in Windows 2000/XP). For larger blocks, directly committing memory through VirtualAlloc is more efficient because you avoid some overhead; it''s a lower-level routine. But that shouldn''t matter for the problem you describe, because both should be able to give you a valid 100 MB block unless your process is running out of virtual memory.

Share this post


Link to post
Share on other sites
spock    217
I don''t have the time to explain HeapAlloc vs VirtualAlloc in detail right now (sorry). You should find plenty of information on the web if you''re interested in that. The former is basically a general-purpose allocator which will request blocks of memory from the OS and return smaller chunks of these blocks to satisfy requests (using a variety of techniques to split blocks and keep track of different chunks), while VirtualAlloc lets you reserve and commit blocks directly in page increments (4K on Win32).

quote:
Original post by Shag
I wouldn''t mind, apart from the fact that I''m dealing with extremely large datasets all the time!



How much memory are you allocating (in total)? Working with extremely large datasets is problematic in general on Windows; anything even approaching 2GB is likely to require special considerations.

Share this post


Link to post
Share on other sites
Jan Wassenberg    999
Sneftel: I''ve malloc-ed ~ 1 GB without problems.
Spock: yeah, you''re left with 2 GB of address space (come on, that ought to be enough for anyone )

Shag: that''s just the beginning:

annoyances:
- often, after starting the IDE, it crashes after loading a project; restart -> it works.
- project properties takes 30 sec to load up the first time
- even with minimal toolbars, the IDE takes up 2 inches of my 15" screen - if I have debug+memory windows up, I''m left with a little sliver of code

serious bugs:
- rebuilds are often necessary to fix breakpoints and update symbols
- RAGE: the debugger proactively fucks up my asm code (inserting 0xcc bytes into addresses, trashing registers)

end(pissing_and_moaning)

Linux can''t be that bad compared to this - I''ll have to give it a try...

Share this post


Link to post
Share on other sites
Shag    122
Cheers for the replies.

The amount of memory I''m allocating varies between 50 and 700mb.

I think I''ll have to use VirtualAlloc, if you think that''s the way forward - I was simply trying to keep the code as cross platform as possible. I guess the odd Win32 API call here and there won''t hurt

Share this post


Link to post
Share on other sites
Jan Wassenberg    999
Almost forgot 2 jaw-droppers:
- disable language extensions => can''t use xor instruction in __asm
- atexit is a ''predefined c++ type'', and can''t be redefined

unbelievable...

Share this post


Link to post
Share on other sites
Jan Wassenberg    999
Real easy to reproduce:
1) new project (console, empty)
2)

int main(int argc, char* argv[])
{
__asm
{
xor eax, eax
}

return 0;
}


3) project properties -> c/c++ -> language -> disable language extensions = yes

The funny thing is,
sub eax, eax 
works, as do the few other instructions I had.

Share this post


Link to post
Share on other sites
spock    217
It's not really a bug because without the language extensions, xor (as well as and, or, not, and some others that are less problematic) are "alternate tokens" for C++ operators. So the extension in this case is to treat alternate tokens specially within inline assembly blocks. Those alternate tokens are irritating, but they are part of the C++ Standard.

[edited by - spock on March 16, 2003 7:29:31 PM]

Share this post


Link to post
Share on other sites
sjelkjd    171
quote:
Original post by Jan Wassenberg
Almost forgot 2 jaw-droppers:
- disable language extensions => can''t use xor instruction in __asm


__asm is a language extension. That you can''t use it shouldn''t be a surprise

MSDN:"The Visual C++ compiler offers a number of features beyond those specified in either the ANSI C or ANSI C++ standards. These features are known collectively as Microsoft''s extensions to C and C++. These extensions are available when the /Ze option, the default, is specified and are not available when the /Za option is specified"

Share this post


Link to post
Share on other sites
sjelkjd    171
quote:
Original post by Jan Wassenberg

- atexit is a ''predefined c++ type'', and can''t be redefined




I''m guessing this is a 6.0 bug, as it doesn''t happen in 7.0

Share this post


Link to post
Share on other sites
sjelkjd    171
I just wrote a program that allocates 400 MB via new, works fine.

There is nothing wrong with vs.net, there is something wrong with a) your program, or b) your computer.

Share this post


Link to post
Share on other sites