Difference: DiagnosingErrors (1 vs. 3)

Revision 32016-01-21 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="SystemAdministration"

Diagnosing Strange and Generic Errors

Changed:
<
<

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.

    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.)

  3. Search for Design Discrepancies:

    In Release 4.1.b and prior, OR non-GUI client (Java)

    Run: 2.Application Design, 3.Utility, 6.Toolbox, 20.Source Analysis Menu, 1.Orphan Detection, 19.Run Each of the Above

    Run: 2.Application Design, 3.Utility, 6.Toolbox, 11.Conversion Utilities, 4.Check for Duplicate ANO and EMs.

    "No Lines Were Output" means the Application passes this test. If any Applications don't pass, perform:

    1. Run: 11.Conversion Utilities, 2.Reset Process Date Add Fields.
    2. Run: 11.Conversion Utilities, 6.Reset DD for full process.
    3. Perform steps 4) thru 6) below
In Release 4.2 and newer, using GUI client (Java)

Log into Appx and click <Design an Application>, then select the application that was running when the error occurred. The Application Design menu will be displayed. Click on the <Utilities> tab. The following functions can be found under the Design Repair Tools heading on the Utilities menu.

Click <Check for Design Orphans>. The Orphan Detection menu will be displayed. Click <Run Each of the Above>. A report will be created for any processes that contain orphan related errors. Otherwise you will see “No Lines Were Output” if there were no orphan errors. You might want to print any report(s) that show errors. When all the processes have been checked and/or printed, return to the Utilities menu.

From the Utilities menu, Click on Verify ANO’s and EM’s. Similar to the above check, a report may be created listing errors. "No Lines Were Output" means the Application passes this test.

If any processes fails either of these tests, perform the following:

    1. Click Reset Process Date Add (Utility menu)
    2. Click Reset DD For Full Compile (Utility menu)
    3. Perform steps 4) thru 6) below
  1. 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.

  2. 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.)

  3. Delete all of your Applications' EMs again.

    Then rerun the scenario that causes the problem.

  4. 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.
>
>

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.


Deleted:
<
<

<--/commentPlugin-->
 \ No newline at end of file
Added:
>
>

<--/commentPlugin-->

Revision 22012-02-29 - ChrisBrower

Line: 1 to 1
 
META TOPICPARENT name="SystemAdministration"

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:

Line: 8 to 8
 
    1. Run: 11.Conversion Utilities, 2.Reset Process Date Add Fields.
    2. Run: 11.Conversion Utilities, 6.Reset DD for full process.
    3. Perform steps 4) thru 6) below
Changed:
<
<

In Release 4.2 and newer, using GUI client (Java)

Log into Appx and click <Design an Application>, then select the application that was running when the error occurred. The Application Design menu will be displayed. Click on the <Utilities> tab. The following functions can be found under the Design Repair Tools heading on the Utilities menu.

Click <Check for Design Orphans>. The Orphan Detection menu will be displayed. Click <Run Each of the Above>. A report will be created for any processes that contain orphan related errors. Otherwise you will see “No Lines Were Output” if there were no orphan errors. You might want to print any report(s) that show errors. When all the processes have been checked and/or printed, return to the Utilities menu.

From the Utilities menu, Click on Verify ANO’s and EM’s. Similar to the above check, a report may be created listing errors. "No Lines Were Output" means the Application passes this test.

If any processes fails either of these tests, perform the following:

>
>
In Release 4.2 and newer, using GUI client (Java)

Log into Appx and click <Design an Application>, then select the application that was running when the error occurred. The Application Design menu will be displayed. Click on the <Utilities> tab. The following functions can be found under the Design Repair Tools heading on the Utilities menu.

Click <Check for Design Orphans>. The Orphan Detection menu will be displayed. Click <Run Each of the Above>. A report will be created for any processes that contain orphan related errors. Otherwise you will see “No Lines Were Output” if there were no orphan errors. You might want to print any report(s) that show errors. When all the processes have been checked and/or printed, return to the Utilities menu.

From the Utilities menu, Click on Verify ANO’s and EM’s. Similar to the above check, a report may be created listing errors. "No Lines Were Output" means the Application passes this test.

If any processes fails either of these tests, perform the following:

 
    1. Click Reset Process Date Add (Utility menu)
    2. Click Reset DD For Full Compile (Utility menu)
    3. Perform steps 4) thru 6) below
Line: 16 to 25
 
  1. 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.)

  2. Delete all of your Applications' EMs again.

    Then rerun the scenario that causes the problem.

  3. 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.
\ No newline at end of file
Added:
>
>

Comments:

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



<--/commentPlugin-->
 \ No newline at end of file

Revision 12012-02-27 - ChrisBrower

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SystemAdministration"

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.

    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.)

  3. Search for Design Discrepancies:

    In Release 4.1.b and prior, OR non-GUI client (Java)

    Run: 2.Application Design, 3.Utility, 6.Toolbox, 20.Source Analysis Menu, 1.Orphan Detection, 19.Run Each of the Above

    Run: 2.Application Design, 3.Utility, 6.Toolbox, 11.Conversion Utilities, 4.Check for Duplicate ANO and EMs.

    "No Lines Were Output" means the Application passes this test. If any Applications don't pass, perform:

    1. Run: 11.Conversion Utilities, 2.Reset Process Date Add Fields.
    2. Run: 11.Conversion Utilities, 6.Reset DD for full process.
    3. Perform steps 4) thru 6) below

In Release 4.2 and newer, using GUI client (Java)

Log into Appx and click <Design an Application>, then select the application that was running when the error occurred. The Application Design menu will be displayed. Click on the <Utilities> tab. The following functions can be found under the Design Repair Tools heading on the Utilities menu.

Click <Check for Design Orphans>. The Orphan Detection menu will be displayed. Click <Run Each of the Above>. A report will be created for any processes that contain orphan related errors. Otherwise you will see “No Lines Were Output” if there were no orphan errors. You might want to print any report(s) that show errors. When all the processes have been checked and/or printed, return to the Utilities menu.

From the Utilities menu, Click on Verify ANO’s and EM’s. Similar to the above check, a report may be created listing errors. "No Lines Were Output" means the Application passes this test.

If any processes fails either of these tests, perform the following:

    1. Click Reset Process Date Add (Utility menu)
    2. Click Reset DD For Full Compile (Utility menu)
    3. Perform steps 4) thru 6) below
  1. 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.

  2. 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.)

  3. Delete all of your Applications' EMs again.

    Then rerun the scenario that causes the problem.

  4. 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.
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback