Salesforce

How to identify the line number in a program as reported by 4gltrace

« Go Back

Information

 
TitleHow to identify the line number in a program as reported by 4gltrace
URL NameP190827
Article Number000143021
EnvironmentProduct: OpenEdge
Version: All supported versions
OS: All supported platforms
Question/Problem Description
How to identify the line number in a program as reported by 4gltrace
How to see the actual line of code in a program as reported in an error
How to resolve the actual line number as reported by LOG-MANAGER
How to identify the line number in a program shown in ABL Stack trace
Steps to Reproduce
Clarifying Information
Lines in stack traces and in log files do not match up with source code.
Logs can even indicate line numbers beyond the end of the source files.
Error Message
Defect Number
Enhancement Number
Cause
Resolution
When a program line number is reported in the debugger, any LOG-MANAGER or PROFILER output, or any ABL Stack trace in debugalert output or protrace file, this line number corresponds to the actual line number in the finished r-code file.Meaning: This is the line number after the compiler has finished expanding all include files and preprocessors.

To identify the actual line of code that is referenced by that line number, generate the debug-list for the program(s) and cross-reference with those.
To generate a debug list, use the DEBUG-LIST option on the COMPILE statement, e.g:
COMPILE <program-name> <OPTIONS> DEBUG-LIST <output-filename>

Following are some specific examples:
0. The code used to create these examples is in the attached "sample code.zip"
Below assumes the session was run with these startup parameters: -p firstproc.p -clientlog sample.log -logentrytypes 4GLTrace:4 -debugalert

1. The 4GLTrace entries in sample.log will show these lines:
[15/07/02@15:43:19.526+0200] P-006216 T-010128 2 4GL 4GLTRACE       Run secondproc.p PERSIST [Main Block - firstproc.p @ 22]
[15/07/02@15:43:19.526+0200] P-006216 T-010128 3 4GL 4GLTRACE       Return from Main Block [secondproc.p]

Note that:
- A "Return" entry does not have a line number - at that point the AVM is past the end of the code, so there is no reference to report.
- The log-manager logging lists "Main Block" for the main block of a procedure; for an internal procedure or function it will show the actual name.
The [Main Block - firstproc.p @ 22] shows in the debug-list as 
       22   RUN secondproc.p PERSISTENT SET hPRoc.
Note that in the base source code, this is actually line 15. The shift in line numbers here is caused by expanding an include file.

2. The Debugalert stack trace for the message box will show:
--> dosomething secondproc.p at line 14  (.\secondproc.p)
    firstproc.p at line 24  (.\firstproc.p)

Note that:
- The ABL Stack in a protrace file will use the same format as the Debugalert traces.
- These do NOT show "Main Block" for a procedure's main block; if the procedure is in it's main block only the program name is shown.

Cross-referencing the stack trace with the debug lists shows:
"dosomething secondproc.p at line 14" matches with "14     IF AVAILABLE ttSample THEN MESSAGE ttSample.recname VIEW-AS ALERT-BOX." in secondproc.lst
"firstproc.p at line 24" matches with "24   RUN dosomething IN hProc (INPUT TABLE ttSample BY-REFERENCE). /* line 17 in source code, will NOT match up with logs */" in firstproc.lst
Workaround
Notes
Note that, for remote debugging purposes, the DEBUG-LIST file that is used by the debugger must be the DEBUG-LIST file that was generated by the same COMPILE statement that generated the r-code you're currently debugging.  This is because the path to the DEBUG-LIST file is hard coded into the r-code.
Keyword Phrase
Last Modified Date7/10/2020 5:13 PM

Powered by