Thomas Schneider wrote:
When I set it to 2003001 it compiles but gives a segmention fault even though it's global. Maybe there's a limitation to allocating that way?
Then I switched dataprism to be a pointer using 'dataprism: ^trisquare;' as you suggested and changed the calls to be 'dataprism^' (a rather cute trick!) and ... it compiles but still gives me a segmentation fault!
Actually, I was able to reproduce this crash. It happened at the point of "dispose (dataprism)". I changed the memory allocation/deallocation calls, and all works well (with "trimax=8006000"):
procedure themain(var da: text); var dataprism: ^trisquare; (* the data structure for diana *) begin getmem (dataprism, sizeof (trisquare)); writeln(output,' trimdiana -gpc bug',version:4:2); writeprism(da, dataprism^); freemem (dataprism, sizeof (trisquare)); end;
begin writeln ('sizeof trisquare=', sizeof (trisquare) div 1024 div 1024, 'mb'); themain(da); end.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Actually, I was able to reproduce this crash. It happened at the point of "dispose (dataprism)". I changed the memory allocation/deallocation calls, and all works well (with "trimax=8006000"):
But using pointers, instead of a global declaration, doesn't change the fundamental issue - the 2GB linear memory limit of a 32-bit process.
Regards,
Adriaan van Os
On 18 Feb 2013 at 18:11, Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Actually, I was able to reproduce this crash. It happened at the point of "dispose (dataprism)". I changed the memory allocation/deallocation calls, and all works well (with "trimax=8006000"):
But using pointers, instead of a global declaration, doesn't change the fundamental issue - the 2GB linear memory limit of a 32-bit process.
Indeed - but his data structure is a lot smaller than 2gb (at the biggest, it is 488mb; and, with "trimax=2003001", it is 122mb). I am using gpc for Win32, which has the same limit, and there is no segfault (ditto with 32-bit Ubuntu).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Abimbola:
Actually, I was able to reproduce this crash. It happened at the point of "dispose (dataprism)". I changed the memory allocation/deallocation calls, and all works well (with "trimax=8006000"):
You mean the compiler crash or the segmentation fault?
I haven't found the magical incantation to control memory on the Mac. but I did come across 'purge'. http://osxdaily.com/2012/04/24/free-up-inactive-memory-in-mac-os-x-with-purg... Free Up Inactive Memory in Mac OS X with Purge Command
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov http://alum.mit.edu/www/toms
On 18 Feb 2013 at 23:01, Thomas Schneider wrote:
Abimbola:
Actually, I was able to reproduce this crash. It happened at the point of "dispose (dataprism)". I changed the memory allocation/deallocation calls, and all works well (with "trimax=8006000"):
You mean the compiler crash or the segmentation fault?
The segfault. I can't crash the compiler with this code, either under Windows, or Ubuntu.
I haven't found the magical incantation to control memory on the Mac. but I did come across 'purge'. http://osxdaily.com/2012/04/24/free-up-inactive-memory-in-mac-os-x-with- purge-command/ Free Up Inactive Memory in Mac OS X with Purge Command
Try "ulimit".
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The segfault. I can't crash the compiler with this code, either under Windows, or Ubuntu.
Maybe it has to be on Mac OS X 10.7?
Try "ulimit".
Yes, thanks, yesterday someone suggested ulimit -s offline.
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov http://alum.mit.edu/www/toms
-
Adriaan van Os -
Prof A Olowofoyeku (The African Chief) -
Thomas Schneider