FAQ's - APPX Software, Inc. : APPX Utility : APPX System Administration :
How do you diagnose strange or generic errors (such as bus errors, seg faults, attempting to free freed memory errors, or "an internal error has been detected" errors)? | |
Run through the following checklist:
Delete all of your Applications' EMs. Rerun your problem scenario to see if the problem still occurs. Set environment variable APPX_TRAILER_COUNT=40, then re-run the condition that generates the error.
This catches most APPX "stepping on memory" errors, by generating an "mm free() - corrupted trailer" message earlier in your problem scenario. This can be set in the appx.env found in the data directory under the directory containing your APPX engine. (If you're running APPX/Server, any new APPX Application server session fired off from an APPX/Client after appx.env editing will have newly edited appx.env environment variables activated.) Search for Design Discrepancies: From the Utilities menu; Run: ‘Run Each of the Above’ from the ‘Orphan Detection’ process Run: ‘Check for Duplicate ANO and EMs’ (‘Verify ANO’s and EM’s’). "No Lines Were Output" means the Application passes this test. If any Applications don't pass, perform: 1. Run: Reset Process Date Add Fields.
The name of an executable module is derived from the date that the PROCESS record was added for that process. If you happen to get two processes with the same "date added", they'll have the same EM name and nasty things will happen. "Reset Process Date Add" assigns a unique "date added" to every process record.
This resets the Date Compiled fields for all data Field and Domain definitions in an application to NULL and also resets the internal Appx Area Number for each field to zero.
It deletes and then re-creates the given files. When the data dictionary compiler compiles a dictionary, it writes records into those four files. When the process compiler compiles a process, it reads from those files, not the FIELD and RECORD file. So, initializing those files is basically the same thing as deleting your data dictionary and typing it all back in again - you end up with an uncompiled dictionary. 4. Reprocess your Data Dictionary. Analyzes the source form of the data dictionary for errors and inconsistencies and produces a more directly executable form (the compiled form is stored in BITMAP, ELEMENT, FILE, and INITIAL).5. Restructure your enduser data. (This should go quickly - only the /Struct file date/time stamps will need to be reset, to match the newly compiled DD. Restructure changes existing data records into a new form after you've changed (and compiled) a data dictionary.
7. Then rerun the scenario that causes the problem. If your problem scenario still fails, and you're running on a Windows platform, send us your appx.stk 'appx.stk' is a stack dump, telling us something of what goes on inside APPX when cassert error messages occur. You'll find it in the same directory that your 'appx' or 'appx.exe' engine is located. If it is overly large, you may want to delete or rename it, then run your problem scenario one more time to get a clean dump. Send to techsupp: The appx.stk dump, The version# of APPX under which you are running, The release level of your Operating System, A brief description of what the error looks like from the operator's perspective, and a brief description of the Application Design elementes in which the error occurred. | |
See also FAQ: "mm free()-corrupted trailer" | |
[Append to This Answer] | |
2005-Oct-07 9:10am |
Previous: | How do I script imports for windows using APPXUTIL? |
Next: | How do I see the APPX Process Stack? |
|