in what cases should this cause an access violation fault?:

m_pData = new unsigned char[ usWidth * usHeight * usBitDepth ];

where m_pData is:

unsigned char* m_pData

?

The Wymsical Wyvern

When "this" is not a valid pointer maybe?

when (usWidth*usHeight*usBitDepth) > 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

well i know i''m not allocating more than 10^8572498729384 bytes but would (800x600x24) + (50x50x24) + (50x50x24) (3 surfaces that is) be too much? (somehow i seriously doubt it)

i nver thought about the "this" thing..... i''ll check it out



The wymsical wyvern

LOL, k, 800 x 600 x 24 is 12mb heheheh, it should be 800x600x3. Well that was my problem and it was sitting right in front of me

btw, how much memory CAN my program allocate without crashing? or was it a sice of the array that was a problem?

The Wymsical Wyvern

It is compiler, OS, and machine dependent, but here is the answer for VC++ 6.0. All praise MSDN!

Syntax
/HEAP:reserve[,commit]

This option sets the size of the heap in bytes.

The reserve argument specifies the total heap allocation in virtual memory. The default heap size is 1 MB. The linker rounds up the specified value to the nearest 4 bytes.

The optional commit argument is subject to interpretation by the operating system. In Windows NT, it specifies the amount of physical memory to allocate at a time. Committed virtual memory causes space to be reserved in the paging file. A higher commit value saves time when the application needs more heap space but increases the memory requirements and possibly the startup time.

Specify the reserve and commit values in decimal or C-language notation.

Mike Roberts
aka milo
mlbobs@telocity.com

what unit is that in?

i forgot to mention the first time, that this access violation fault occurred in the "kernel32.dll" dll, that seems rather bad doesn''t it? is this my code problem or a windows problem?

The fact that it showed up as being in Kernal32.dll is simply because ALL access violattions will show up in kernal32.dll. See kernal 32 manages the protected mode processes (all processes really) and the memory allocation / deallocation. ... the C++ heap manager simply allocated memory using the Windows functions ... so if Windows can''t handle it ... then IT will be the one to throw the error.

Just last week my program had a dangling pointer (causing access violation) issue in a function of mine that used ostringstream''s. I tracked the bug and found that I had no error ... for it was crashing on a line that simply piped a string literal (cstyle) into a stringstream ... but apparently the standard library included with VC++ 6 cannot handle as much static data (strings) as i''m using in my program ... cause when I omited half the string .. it worked

Allocations can cause access violations if you corrupt your heap (that is, write over heap data structures via an invalid pointer.)