Filling memory causes application crash...
Dear all,
I have a question about allocating 2MB memory then filling it...
@ Platform:
=> DOS, and application is compiled/linked via Watcom C + DOS32/A (...memory model is "flat" mode)
@ phenomenon:
1. I allocate 2M memory by calloc() function. Then I got "!NULL" and it means allocating 2MB memory is ok( right ? )
2. then I tried to "fill" this 2MB memory by for loop(one byte by one byte) like below:
for( DWORD i=0; i<0x200000; i++)
{
*((BYTE *)(A[0].B[0]->C) + i ) = 0x5A; // C is 4-byte address value
}
here :
* DWORD means "unsigned long(4-byte)" and 0x200000 means "2MByte"
* in actual case the value of pointer(to allocated memory) is 3019AF3C(~768MB) <- running in flat mode...
3. after filling this range of memory(2MB) the application crashed...
@ my observations:
1. if allocating 2MB and no fill(no write data to memory) => OK
2. if allocating 2MB and just fill the former 32 bytes => OK
3. if allocating 4KB and fill all => OK
my question is: why can't I filling this 2M memory totally "even memory allocation succeeds" ?
Re: Filling memory causes application crash...
Perhaps you should post the smallest and simplest compilable program that you expect to run perfectly fine to do this but which demonstrates the problem you described.
Re: Filling memory causes application crash...
1. allocate memory by below function: ( assume w = 0x200000 and h = 1, size = 1(BYTE) )
---------------------------------------------------------------------------------------
void* malloc2D( WORD w, WORD h, WORD size )
{
WORD y;
void **a = (void **) calloc( (h*sizeof(void *) + w*h*size), sizeof(BYTE) );
for( y=0; y<h; y++ )
{
a[y] = ((pBYTE)(a+h)) + y*w*size;
}
return a;
}
2. assign pointer's value to "C" then use for loop to fill this allocated memory:
------------------------------------------------------------------------
for( DWORD i=0; i<0x200000; i++)
{
*((BYTE *)C + i ) = 0x5A; // C is 4-byte address value
}
// in above example C's value is 0x3019AF3C !
F.Y.I
Re: Filling memory causes application crash...
Quote:
Originally Posted by
liaooo
1. allocate memory by below function: ( assume w = 0x200000 and h = 1, size = 1(BYTE) )
1) Use code tags when posting code.
2) Is this 'C' or C++?
3) Post a complete example. This means a main() program and the call to the routine -- don't just pluck out bits and pieces of code. No one knows when or where that function is called, since you could have trashed memory doing something else that you didn't post.
4) Why is your code to allocate a 2-d array of BYTE so convoluted? Assuming this is 'C' and not C++:
Code:
#include <stdlib.h>
BYTE** malloc2D( WORD w, WORD h )
{
BYTE** ptr = (BYTE **)malloc( h * sizeof(BYTE*) );
if ( ptr )
{
BYTE *ptrPool = (BYTE *)malloc( h * w * sizeof(BYTE) );
if ( ptrPool )
{
WORD i;
for (i = 0; i < h; ++i, ptrPool += w )
ptr[i] = ptrPool;
}
else
{
free(ptr);
ptr = NULL;
}
}
return ptr;
}
void deallocate2D( BYTE** ptr )
{
free(ptr[0]);
free(ptr);
}
int main()
{
BYTE **byte2D = malloc2D(0x200000, 1);
if ( byte2D )
{
WORD i;
// fill in data with 0x6A for the first row
for ( i = 0; i < 0x200000, ++i )
byte2D[0][i] = 0x5A;
deallocate2D( byte2D ); /* free the memory */
}
}
I didn't compile the code above, but that is basically how to allocate a 2-d array where the data is in one contiguous block. The row pointers are allocated first, the data is allocated second, and then you loop pointing the row pointers to the data. Then when deallocating, two calls to free() are done, one to deallocate the data, and the second to deallocate the row pointers.
Regards,
Paul McKenzie
Re: Filling memory causes application crash...
Quote:
Originally Posted by
liaooo
1. allocate memory by below function: ( assume w = 0x200000 and h = 1, size = 1(BYTE) )
---------------------------------------------------------------------------------------
void* malloc2D( WORD w, WORD h, WORD size )
I'm quite curious how you're going to do that with a 16-bit WORD... ;)
And I have no idea how DOS and the flat memory model would ever fit together: DOS runs in 16-bit real mode which doesn't support that memory model at all. If you're using some DOS extender, OTOH, I'm at my wit's end personally (never have written code for them). At least you need to present more details here in this case.
It is possible to work with chunks of memory larger than 64 K in real mode (MS called that "huge memory model" with "huge pointers"), but in this case certain restrictions regarding the use of pointers need to be observed to accomodate to the segmented addressing scheme. And that may very well be specific to your Watcom compiler, and then we'd need more details as well. Eventually that scenario looks unlikely to me to be yours, because that way you couldn't access more memory than 640 KB (1 MB, theoretically) either, and you claimed you were able to allocate 2 MB.
Re: Filling memory causes application crash...
To Paul McKenzie,
I used Wacom C++ to compile code. Besides, the code I listed to allocate 2 dimensional memory is ok and I think there are 2 adv:
a) only one free required because only 1 malloc used
b) the memory buffers are "adjacent" ( that is, continuous memory portions ) <- this way allocates memory for pointers then immediately allocates for buffers.
To Eri523,
I made a big mistake in malloc2D when considering the buffer width :( (as you said). After declaring it as unsigned 32bit integer filling memory is OK now ! Thanks :)
It is true that the application is running in flat memory mode because I combined both Watcom C and DOS32/A to achieve this goal ( see http://dos32a.narechk.net/index_en.html and you get lots of info on www)
Actually I did not know well about this combination... I just copied the sample code, modified, tried then found it can access the memory above 1M <- that is what I want ^_^
* The reason why I need this is I was writing an application to test HW in DOS mode, thus I need to access its memory-mapped I/O and this address is always > 1MB.
* Besides I need to communicate with device via large-sized physical memory thus I need to write/read memory...
Now with this mode I can:
- read the memory address > 1M, no matter what the memory type is ( here memory type means: physical memory introduced by installed DRAM module or memory-mapped I/O for device...)
- write the memory > 1M
- allocate large-sized memory Ex. 4M (> 640K) and fill it !
Thank all of your support !