Re: [BLACKBOX] Illegal Memory Access with Windows 7 - Update 3
Hello
A colleague has coded a version (a different random number generator!) of this test in C#.NET for X86 (ie a 32-bit version).
The results on my two machines are:
The statistics are: (Windows 7 / Windows XP)
Number of good allocations: 6148 / 6082
Number of failed allocations: 96354 / 96318
Maximum amount allocated: 1795.4 / 1805.0 Million Bytes.
So the 800 MByte memory limit does not seem to come from Windows 7.
It looks like there has been some change to the WinApi interface that means that the way BlackBox gets its memory no
longer works as well as it did / should.
Any ideas, anyone?
Regards
Robert
From: BlackBox [mailto:BLACKBOX{([at]})nowhere.xy
Sent: 15 August 2013 14:05
To: BLACKBOX{([at]})nowhere.xy
Subject: [BLACKBOX] Illegal Memory Access with Windows 7 - Update 2
Romiras: – Thanks for your interesting and useful test module.
I have modified it a little (attached as StdCoded & .pdf).
All:
I have run it on two systems:
Both: 64-bit operating systems, 8 GByte RAM, patched BlackBox kernel and compiler as described below.
The test does not crash.
The statistics are: (Windows 7 / Windows XP)
Number of good allocations: 3343 / 4866
Number of failed allocations: 99057 / 97534
Maximum amount allocated: 802,561,342 / 1607,954,078 Bytes.
Conclusion: Windows 7 only provides access to half the memory available with Windows XP.
I think I understand the XP / BlackBox 1600 MByte limit. A 31-bit address space give a potential for 2 GByte. In BlackBox
400 MByte is allocated to static / stack stuff, leaving 1600 MByte for the heap. The figure 1600 is a BlackBox Kernal constant
chosen by Oms after discussion with their customers.
I do not understand the Windows 7 limit of 800 MByte. Can it be explained and increased?
Can someone run a version of this test code under another 32-bit compiler or language? I would like to understand if the limit
is a Windows 7 limit, or if there is some remaining BlackBox issue that might be easy / possible to fix.
Chris: Is GPCP a 32-bit or 64-bit system?
Thanks,
Regards,
Robert.
From: BlackBox [mailto:BLACKBOX{([at]})nowhere.xy
Sent: 21 July 2013 12:29
To: BLACKBOX{([at]})nowhere.xy
Subject: Re: [BLACKBOX] AW: [BLACKBOX] Illegal Memory Access with Windows 7
Hi, everyone.
It looks that I found the way how to cause bug mentioned above. For this purpose I used small GC benchmark for D language run-time and adapted it for Component Pascal with some modifications.
I tested on Windows XP with 2 GB, Windows 8 with 4 GB and in Linux/Wine with 4 GB. On all of these machine I reproduced a bug.
If I use patched version of module Kernel by user luowy from September 2012, a bug didn't reproduced for me.
Please compile and run an encoded module TestGCAlloc1 attached below:
StdCoder.Decode
--- end of encoding ---
2013/7/11 Campbell, Robert (Selex ES, UK) <robert.d.campbell{([at]})nowhere.xy
Chris
Thanks for this - you and Helmut are so much more organised than me!
Marc's email contains updated versions of
- Dev/Mod/Cpc486.odc
- System/Mod/Kernel.odc
& instructions on how to install these files.
Luowy's email contains a later update to Kernel.odc.
There is a problem with Cpc486. The problem involves mixing INTEGERs & LONGINTs, and has been discussed here more than once.
The fix is to add one line; this fix was provided by Louwy on 19-Dec-2011 (give or take a day or two!).
I have just installed Marc's version of Cpc486 + Louwy's INTEGER fix, and Louwy's version of Kernel.
This has certainly helped the Window's 7 memory problem; I have not used it enough yet to know if it is now reliable, but will
report on that later.
[…]
Thanks, Robert
Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Received on Thu Aug 15 2013 - 16:50:24 UTC
This archive was generated by hypermail 2.3.0
: Thu Sep 26 2013 - 06:29:51 UTC