Diagnosing Strange and Generic Errors

To 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:

1. Delete all of your Applications' EMs. Rerun your problem scenario to see if the problem still occurs.

2. Set environment variable APPX_TRAILER_COUNT=40, then re-run the condition that generates the error. See Setting Environment Variables to set an environment variable. This catches most APPX "stepping on memory" errors, by generating an "mm free() - corrupted trailer" message earlier in your problem scenario.

3. Search for Design Discrepancies:
   

   In character mode go into Application Design for the problem application:
   
   

   Run: 3.Utility, 6.Toolbox, 20.Source Analysis Menu, 1.Orphan Detection, 19.Run Each of the Above
   Run: 3.Utility, 6.Toolbox, 11.Conversion Utilities, 4.Check for Duplicate ANO and EMs.

   
   In GUI Mode:
   
   

   Go into Application Design for the problem application and click on the "Utilities" tab.
   Click "Check for Design Orphans". The Orphan Detection menu will be displayed. Click "Run Each of the Above".
   Click on Verify ANO’s and EM’s.

   
   
   

If the Orphan Detection report identifies any orphan design objects, add the missing parent and then delete it. That should remove the parent and the orphan. For example, if an orphan Image is identified, add the missing Process and Frame, then delete the Process. Rerun the Orphan Detection to ensure the orphans are gone. If an orphan Item is identified, you will have to add the Process, Frame, and Image, and so on.

If the Duplicate ANO and Em report identifies any problems, then follow this procedure:

1. Reset the ANO and Ems by:
   1. Click Reset Process Date Add (Utility Tab or 3.Utility, 6.Toolbox, 11.Conversion Utilities, 1) Reset PROCESS DATE ADD Fields)
   2. Click Reset DD For Full Compile (Utility Tab or 3.Utility, 6.Toolbox, 11.Conversion Utilities, 6) Reset DD for full process)
      
      
2. 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), Initialize Files.

3. Go back to Application Design and Process the DD.
   
   
4. 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.)

5. Delete all of your Applications' EMs again and rerun the scenario that causes the problem.

6. 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:

   1. The appx.stk dump,
   2. The version# of APPX under which you are running,
   3. The release level of your Operating System,
   4. A brief description of what the error looks like from the operator's perspective, and
   5. A brief description of the Application Design elements in which the error occurred.

Comments:

Read what other users have said about this page or add your own comments.

---