Robert and Romiras,
I would recommend to release the allocated memory after the inner loop and before
you output anything to the log because writing to the log will
allocate more memory, which might not be available after the inner loop
without setting the array-elements to NIL.
- Josef
----- Original Message -----
From: Campbell, Robert (Selex ES, UK) <mailto:robert.d.campbell{([at]})nowhere.xy
To: BLACKBOX{([at]})nowhere.xy
Sent: Thursday, August 15, 2013 3:04 PM
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: 3347 / 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.
********************************************************************
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Mon Aug 19 2013 - 11:20:44 UTC