Operating System - OpenVMS
1748102 Members
5352 Online
108758 Solutions
New Discussion

How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

 
chadjoan
Occasional Contributor

How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

Hello,

 

How do I get C program tracebacks to print source line numbers instead of listing line numbers?

 

I find it very frustrating to have to look at a listing file every time I want to see the location of a single call in the stack trace.  Running things in debug mode all the time is not practical either.  There has to be a better way!

 

Thanks,

- Chad

11 REPLIES 11
Hoff
Honored Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

That's not the way the C compiler works on VMS.  (And since the compiler only sees the source code after the C preprocessor has done its preprocessing, those line numbers are the source line numbers.)

 

Here are details of tracebacks and particularly of debugging an access violation (ACCVIO) error, and of using the listings files and linker maps to investigate an ACCVIO crash.

H.Becker
Honored Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

>>> Running things in debug mode all the time is not practical either. 

 

Depending on what kind of problem you have to solve, a process dump can help. You would compile your source with /debug and link with /dsf. The linker then only generates a debug symbol file. Running the image will not get you into the debugger. Now, if you ask for a process dump with SET PROC/DUMP and if there is a problem causing your program to terminate with a traceback, a dump file is written. ANALYZE/PROCESS fires up the debugger and you can do a post-mortem debug with source code. See the debugger manual for all the details.
 
PS: Don't be surprised when on Alpha systems the traceback now doesn't show any line info at all. That's a known "feature", which wasn't ported to Integrity servers.
Hoff
Honored Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

Process dumps will work, certainly.  That's certainly better than the usual "unhandled" stackdumps.

 

When moving past the line numbers, implementing application-integrated logging and debugging helps with application availability and troubleshooting.

 

The state of VMS application debugging is comparatively primitive and - beyond process dumps and the signal- handling scaffolding - the state of the available application logging is inordinately primitive.  There isn't an integrated framework for application logging in OpenVMS.  While you can (and should) tie into signal handling, and you can choose among  the various different logging mechanisms (via OPCOM and OPERATOR.LOG, via accounting, via security audits, by invoking the debugger from within the application) available, there are unfortunately no "modern" distributed application-targeted logging tools integrated into OpenVMS.

 

There are third-party and open-source logging add-ons available, and these allow a programmer to incorporate monitoring and distributed logging into an application.

John McL
Trusted Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

What's so difficult about opening the source in one editor buffer, loading the listing in another editor buffer, searching the second buffer for the specified line number, then finding the matching line in the main buffer?

 

I use this all the time when debugging compilation errors.

 

Of course some might say that the solution is to have fewer errors in the executable code ;-) 

chadjoan
Occasional Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?


@John McL wrote:

What's so difficult about opening the source in one editor buffer, loading the listing in another editor buffer, searching the second buffer for the specified line number, then finding the matching line in the main buffer?

 

I use this all the time when debugging compilation errors.

 

Of course some might say that the solution is to have fewer errors in the executable code ;-) 


Works alright if your program is entirely in one source file.  Somewhere around when the trace spans 3+ files this gets really old quite fast.

jreagan
Advisor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

For compile time errors, if you use /DIAG and LSE, the .DIA file contains enough information for the editor to find the exact line/column in whatever source file has the diagnostic.  Look at LSE's COMPILE and REVIEW commands.

 

For run time errors with tracebacks, neither the listing line number (the traditional form on OpenVMS) nor the source line number is really sufficient to find the source file and source line.  Since you only have image name, module name, routine name, and line number, you always have to "know" something to find the source file.

 

Of course all the information you need is inside the debug records (where the compiler uses source line numbers, not listing line numbers).

 

Hoff
Honored Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

What's so difficult?  Nothing, really.  Well, after using a modern IDE, what becomes difficult is opening the source in multiple editor buffers, loading the listings in other editor buffers, searching the various buffer for the specified line number, and then finding the matching line in the main buffer.  Yeah; that's pretty much what becomes difficult, once you've used an IDE.  That, and refactoring, operating without syntax highlighting, source code correction, and a variety of other minor details.  :-)

 

But more seriously, your sequence is entirely feasible.  It's how it's done, on VMS.  It's just that it's more work than it should be - computers are good at this sort of stuff, after all - and it's more slogging and more details than most folks are accustomed to.

 

On VMS, LSEDIT is one of the few IDE-like tools that's tied into the compiler analysis files.  Which means it's good at tracking down compiler-detected errors.  But it's not so good at finding the source code associated with the trigger for a run-time stackdump.  And that's a task for which LSEDIT or any similar developer-focused tool should be much better at.

 

And yes, I've gone from patching the running core and patching executables to using IDEs.  And I really like a good IDE.   A good IDE makes developing for and dealing with even a smaller code-base vastly easier, and more efficient.

Mike Kier
Valued Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

I've often used LSE in conjunction with the debugger.  When single stepping through a program, entering EDIT at the debug line puts you in LSE at that line in the appropriate source file.

 

I've not tried the same when using an ANALYZE/PROCESS_DUMP session of an image with a DSF file to know if it will work from the information in the call stack.

Practice Random Acts of VMS Marketing
John McL
Trusted Contributor

Re: How do I get C program tracebacks to print SOURCE line numbers instead of LISTING line numbers?

Doesn't your stack trace list the function in which the line appears?  Searching your source files for that function might identify the specific file a whole lot faster. 

 

It might be worth adding a flag comment in the statement for each function so that you can use that as an additional tag so that you avoid listing all the calls of that function.  To search for the function in multiple files you would use something like

 

$ SEARCH/MATCH=AND *.C <my_flag>,<fn_name>)