Friday, February 27, 2009

What's fixed in CA-Clipper 5.2b


The following information on the CA-Clipper 5.2b patch was extrated from 52abi.txt which came with the patch. This is an important patch as it fixes 28 known bugs !!!

The problems resolved by CA-Clipper 5.2b include:

1. Fixed a Virtual Memory Integrity Failure in FOPEN() when the file name is numeric instead of a character string.

2. Fixed a Virtual Memory Integrity Failure when calling AADD() to increase the size of an array.

3. Fixed a Virtual Memory Integerity Failure that occured when an ACHOICE() user function deleted elements from the menu selection array. ACHOICE() now allows the user function to add, delete, or modify existing elements without causing any problems in ACHOICE().

4. Fixed a Virtual Memory Integrity Failure in the Internal Runtime Event System. This was causing the DBFCDX driver to hang as well as various "unexplainable" errors.

5. Fixed a Virtual Memory Integrity Failure in the debugger when viewing multiple nested arrays. Tbrowse was producing a parameter error when viewing multiple nested arrays. In some instances this produced a Virtual Memory Integrity Failure.

6. Fixed a Virtual Memory Integrity Failure in the debugger's memory allocator. (STAR Issue# 737689)

7. Fixed INDEXKEY() memory corruption problem. INDEXKEY() would occasionally return a garbage string when called repeatedly. This sometimes caused a Virtual Memory Integrity Failure.

8. Fixed MEMOEDIT() buffer memory corruption problem. This occurred when MEMOEDIT() was called with a user defined function. This would result in various memory related errors including a Virtual Memory Integrity Failure.

9. Fixed slow disk I/O on replaces on large DBF's with non-unique indexes. The performance has been improved to a speed which is comparable to CA-Clipper 5.01a.

10. Fixed the releasing of all relations (in all workareas) when any child dbf was closed. Now closing a child database releases only the relations that it is involved with.

11. Fixed the DBFNDX Replaceable Database Driver so that it now properly seeks on a date value with SET DELETED ON.

12. Fixed DBCREATE() to properly return a NIL value as documented.

13. Fixed INDEXORD() so that it now returns a zero when no database is open rather than generating a runtime error.

14. Fixed some occurances of internal error 1210 (database and index are out of sync).

15. Fixed many occurances of internal error 415 (can not open external overlay file).

16. Fixed the Runtime Memory Manager so that it now returns an EG_MEM (5300 "Memory Low Warning") before generating a memory exhausted error.

17. Fixed Runtime failures that occured when CA-Clipper mistakenly tried to use non-existent EMS memory.

18. Fixed FREAD() so that it does not modify variables that it shouldn't have access to.

19. Fixed BROWSE() so that it no longer causes the repositioning of a file to BOF() when editing takes place in a new record.

20. Fixed the debugger so that it is no longer necessary to specify the default file extension (.PRG or .PPO) when opening a file.

21. Fixed the debugger so that it correctly searches the path (indicated by the PATH environment variable) when searching for a file to open.

22. Fixed the debugger so that it does not produce "Argument error +" when the F6 key is pressed to view databases.

23. Fixed DBU so it now correctly parses a file name that contained a drive letter and colon (:) but no backslash (\) (such as C:TEMP).

24. Fixed numerous bugs in the R.L. utility.

25. Fixed the compiler screen to include the missing /t and /z options in order to match the documented options.

26. Fixed the spelling of OrdDestory to OrdDestroy in STD.CH for the DELETE TAG command.

27. Fixed the "Guide to CA-Clipper" .NG file so that the Norton Guide engine may now be unloaded from memory.

28. Enhanced the //INFO command line parameter to show what message and collation driver is linked in.

Technical Note: The Virtual Memory Integrity Failure Error Message

The Virtual Memory Integrity Failure error message (or VMIF for short) refers to a problem that is neither well documented nor well understood. In this technical note, we will explore what the VMIF message indicates, some of the common reasons it occurs, and what measures to take if you encounter one.

CA-Clipper uses a virtual memory manager to allow applications to access more strings, arrays, and objects than conventional memory would otherwise allow. It accomplishes this by swapping information to and from expanded memory or disk as needed. Each virtual data item (called a segment) has an entry in a descriptor table that maintains its current location and length. A segment's length can be up to 65,518 bytes, while its location may be conventional memory (resident), disk or EMS (non-resident). When CA-Clipper receives a request for non-resident data, it always checks the segment's descriptor entry to ensure that it's length is non-zero. Any descriptor whose length is zero is, by definition, invalid because VM does not allow zero-byte segments. Thus, a zero length segment is interpreted as a corruption, and the VMIF error message is displayed.

Along with the VMIF message is a hexadecimal address that indicates the address of the corrupted descriptor table element. This information may be useful to the CA-Clipper Technical Support as well as the development staff. C and Assembler programmers may also find this information useful in determining if and how their code caused the corruption. A special case is the address 0000:0000. It indicates that a NULL and (possibly uninitialized) pointer was used to access virtual data.

While it is true that the VMIF message occurs for exactly one condition, that condition can be created in many different ways. Research indicates that the conditions that lead to a VMIF can be broken down into three distinct categories.

First, several VMIFs can be attributed to Clipper programming bugs. While a VMIF should never occur solely on the basis of executing Clipper code, a combination of inadequate error detection on the part of Clipper runtime and a violation of proper programming practices may cause the error to occur. Examples of this have been: calling FOPEN() with numeric data for the file name, deleting array elements from within an ACHOICE() UDF, and assigning NIL to any TBROWSE instance variable that requires a character value. (Please note that the TBROWSE VMIFs were fixed in the 5.01a release and the ACHOICE() and FOPEN() VMIFs are fixed in the 5.2b release by producing an error when improper values are used.)

The second category is within the CA-Clipper runtime support libraries. CA-Clipper's runtime support libraries constantly issue calls to the VM system throughout the normal execution of a Clipper application. On occasion, specific conditions pertaining to runtime activities are not properly handled internally, creating conditions that eventually result in a VMIF. These instances are always considered problems by the development staff.

The last category is external code typically written in C or Assembler by CA-Clipper programmers and third party library developers. These are usually caused by improper use of one of CA-Clipper's APIs or by changing the functionality of something within CA-Clipper's runtime that is assumed to remain constant.

Although CA-Clipper's VM system provides detection and reporting, it is almost never the cause of a VMIF.

VMIFs are commonly detected long after the actual corruption occurred. A module may store a zero-length segment in the segment descriptor table either through use of VM or by writing to a wild pointer. This corruption will not be detected until a VM segment is accessed that requires the corrupted segment to be discarded, or swapped to disk or EMS. The Clipper VM subsystem is demand-based. This means that it only performs swapping when swapping is absolutely required. If a VMIF consistently occurs at a specific point in the execution of an application, it is often not actually caused at this point. It tells us that a corruption has occurred, but has no means for determining the cause of the corruption or when the corruption actually occurred.

Because VMIFs are detected when the VM system attempts to swap in memory, a change in the amount of conventional memory available when an application is executed changes the possibility of the VMIF occurring. When sufficient real memory is available, VM has no need to perform any swapping and any possible VMIFs will not be detected. When less real memory is available to an application, the entire profile of swapping is changed, and may prevent the VMIF from occurring in a constant location.

This raises the question of how to ensure that the VM system is being called during the testing phase of application development. A simple and effective method is to use CA-Clipper's //X: parameter to decrease the available memory as much as is feasible. This will ensure that the VM system will be called with the most frequency. (The //X: parameter is detailed in the Runtime Environment chapter of the CA-Clipper 5.2 Programming and Utilities Guide.)

If a VMIF occurs, try to determine how to reproduce the problem at will and if possible, isolate it to a small example and immediately contact your CA-Clipper Technical Support Representative. The CA-Clipper Quality Assurance team is also constantly searching for occurrences of VMIFs. Either way, the CA-Clipper Development team is anxious to correct all internal VMIFs as quickly as possible.

No comments:

Post a Comment

Welcome to Clipper... Clipper... Clipper


In 1997, then using Delphi 3, I had already created 32-bits Windows applications for HRIS, ERP and CRM. In 2007, using Ruby on Rails, an AJAX powered CRM site running on Apache & MySQL was created and I am now using Visual Studio .Net 2008 to create web-based projects and Delphi 7 for Win32 applications using SQL2005 & DBFCDX.

So, why then am I reviving the Original Clipper... Clipper... Clipper via a Blog as CA-Clipper is a programming language for the DOS world ? Believe it or not, there are still some clients using my mission-critical CA-Clipper applications for DOS installed in the late 80's and up to the mid 90's. This is testimony to CA-Clipper's robustness as a language :-)

With the widespread introduction of Windows 7 64-bits as the standard O/S for new Windows based PCs & Notebooks, CA-Clipper EXE simply will not work and it has become imperative for Clipper programmers to migrate immediately to Harbour to build 32/64 bits EXEs

Since 28th January 2009, this blog has been read by 134,389 (10/3/11 - 39,277) unique visitors (of which 45,151 (10/3/11 - 13,929) are returning visitors) from 103 countries and 1,574 cities & towns in Europe (37; 764 cities), North America (3; 373 cities) , Central America & Caribeans (6; 13 cities), South America(10; 226 cities), Africa & Middle-East (12; 44 cities) , Asia-Pacific (21; 175 cities). So, obviously Clipper is Alive & Well : -)


TIA & Enjoy ! (10th October 2012, 11:05; 13th November 2015)


Original Welcome Page for Clipper... Clipper... Clipper

This is the original Welcome Page for Clipper... Clipper... Clipper, which I am republishing for historical and sentimental reasons. The only changes that I have made was to fix all the broken links. BTW, the counter from counter.digits.com is still working :-)

Welcome to Chee Chong Hwa's Malaysian WWW web site which is dedicated to Clipperheads throughout the world.

This site started out as a teeny-weeny section of Who the heck is Chee Chong Hwa ? and has graduated into a full blown web site of more than 140 pages (actually hundreds of A4 size pages) ! This is due to its growing popularity and tremendous encouragements from visiting Clipperheads from 100 countries worldwide, from North America, Central America, Caribbean, South America, Europe, Middle-East, Africa and Asia-Pacific. Thanx Clipperheads, you all made this happen !


What is Clipper ?

You may ask, what is this Clipper stuff ? Could Clipper be something to do with sailing as it is the name of a very fast sailing American ship in the 19th century ?

Well, Clipper or to be precise, CA-Clipper is the premier PC-Software development tool for DOS. It was first developed by Nantucket Corporation initially as a compiler for dBase3+ programs. Since then, CA-Clipper has evolved away from its x-base roots with the introduction of lexical scoping & pre-defined objects like TBrowse. As at today, the most stable version ofClipper is 5.2e while the latest version, 5.3a was introduced on 21 May 1996.

As at 11th November, 1996, an unofficial 5.3a fixes file was made available by Jo French. See the About CA-Clipper 5.3a section for more details. BTW, Jo French uploaded the revised 5.3a fixes file on 20th November, 1996.

Latest News

The latest news is that CA has finally released the long-awaited 5.3b patch on 21 May, 1997.

For 5.3b users, you must a take a look at Jo French's comments on unfixed bugs in 5.3b.

BTW, have you used Click ? If you're a serious Clipperprogrammer and need an excellent code formatter, Click is a natural choice. How to get it ? Simple, access Phil Barnett's site via my Cool Clipper Sites.

32-bits Clipper for Windows ?

Have you tried Xbase ++ ? Well, I have and compared to Delphi (my current Windows programming tool of choice), I'm still sticking to Delphi.

Anyway, you should visit the Alaska Home Page. Give it a chance and then draw your own conclusions !.

The Harbour Project

Is this the future of Xbase ? Take a look at at the Harbour Project

You are Visitor # ...

According to counter.digits.com, you are visitor since 3 June 1996.

If you like or dislike what you see on this website, please drop me a line by clicking the email button at the bottom of this page or better still, by filling out the form in my guest book. If you are not sure what to write,click here to take a look at what other Clipperheads have to say.