APPX is the Premier Development and Runtime Environment for Business Application Software
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) 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.


2. Run: Reset DD for full process.

   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.
Resetting the compile date to null forces all fields and domains to recompile.
The Appx Area Number is how Appx locates data in memory. We have had bugs in the past that caused two or more fields to have the same area number meaning they shared the same memory space, which is a very bad thing. Setting the area number to zero for all fields forces appx to assign all new area numbers and thus fix the memory corruption problem.


3. Initialize the 4 compiled DD files (BITMAP, ELEMENT, FILE, INITIAL) and reprocess the Data Dictionary. These can be initialized in System Administration, Design File Management, File Selection (select these four files), then Initialize Files.

   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.


6. Delete all of your Applications' EMs again.

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: (Xref) "mm free()-corrupted trailer"

[Append to This Answer]
2005-Oct-07 9:10am
Previous: (Answer) How do I script imports for windows using APPXUTIL?
Next: (Answer) How do I see the APPX Process Stack?
This document is: http://board.appx.com/cgi-bin/fom.cgi?file=393
[Search] [Appearance]
This is a Faq-O-Matic 2.719.
Copyright 2003 by APPX Software, Inc. All rights reserved.