Have Intel Parallel Studio XE Cluster Edition Version 16.0 update 3 installed on Cent O/S 7.2 and am having debugger issues (gdb-ia).
Using Eclipse neon on KNL with PHOTRAN extension.
The application is
C main compiled using the Intel mpiicc (the C main is an MPI process stub)
C++ code with OpenMP (num threads set to 1)
Intel Fortran .so library which is being debugged
gdb-ia version 7.8-16.0.768
Note, on startup it emits
warning: Cannot parse .gnu_debugdata section; LZMA support was disabled at compile time
First issue I had, but I believe is corrected now, is the documentation on how to install and use Intel's version of gdb (gdb-ia) has incorrect instructions. The documentation references compilervars.sh not psxevars.sh...
... nor debuggervars.sh (in a different folder)
Please correct the documentation.
Second issue, which may be the source of my third (and pressing) issue is, the "standard" gdb debugger uses a command file named .gdbinit. The Intel documentation does not state if this file is to be used, or if there is an alternate "init" file to be used (.gdb-iainit).
Is there an alternate gdb command file?
Now for the pressing issue.
I am trying to find out why a convergence routine is failing to converge in the Fortran .so file. My SOP is to let the program run until I think it is hung, then press Pause all (||) in the Eclipse neon IDE.
Usually this breaks into the hung Fortran .so library... and I can see in the Variables Window the function's call arguments and local variables.
The issue though, is when I go up the call stack, the variables will not display. If I go back down to the lowest level, the variables display.
When I compile the Fortran .so file with Provide Frame Pointer, the call stack does not show the C++ code stack. But it does show when omitting the frame pointer.
After I Pause (SIGINT) into gdb-ia, in the Fortran .so library, I am unable to Step Over/Into/Out, or Continue
But note, if I revert back to gdb, I can Step Over/Into/Out, and Continue, however, I still have the missing variables up the call stack.
If anyone has some hints on how to resolve this, I'd appreciate the education.
Additional note. When I use gdb (so I can step), it usually runs for several seconds (10's of seconds) then something terminates the application.
Is there a process killer that kills what it thinks is a hung job? (and if so, how to disable)
BTW, can someone answer the question in the first post:
>>the "standard" gdb debugger uses a command file named .gdbinit. The Intel documentation does not state if this file is to be used, or if there is an alternate "init" file to be used (.gdb-iainit?).
Is there an alternate gdb command file?
gdb-ia from initial release PS XE Cluster edition 2017, at least isn't crashing when opening Variables window... but it is having an issue displaying user defined types.
Failed to esecute MI command:
-var-create - * crames (my UDT)
Error message from debugger back end:
-var-create: unable to create variable object
Any help would be appreciated.
If it doesn't crash, I can at least edit code and insert pertinent variable copies from UDT's to local temps.
2017 gdb-ia crashes when Variables window is open, and I navigate the stack frame.
IOW with Variables window present, if I go up a stack level, upper level variables do not show...
... .AND. Step or Continue do not work.
However, with Variables window closed, I can Step and continue. I can use the expressions window to examine non-user defined types. A bit cumbersome, but at least it works.
Using the compilervars.sh is OK. The psxevars.sh contain the compilervars.sh + other init scripts. However, if you want to use Intel(R) MPI, you also need to source mpivars.sh in addition to compilervars.sh. If you use psxevars.sh instead, it does it all in one rush for you.
The documentation only specifies the minimum setup. If you have additional requirements you need to care about that in addition (e.g. sourcing the mpivars.sh).
Like with a vanilla GDB, .gdbinit is optional. If Eclipse asks you for it, and you don't have any need for common initialization of your debug sessions, then don't specify it. Of course, gdb (and gdb-ia) will always check in $HOME and the current working dir whether a .gdbinit is available and use it. Please refer to the official GDB documentation. gdb-ia uses exactly the same .gdbinit as any vanilla GDB.
Compressed debug information support will be added in the future (LZMA). We already work on that.
Reg. the call stack issues, please provide a test case. Have you made sure that debug information is available? If there is no debug information, there is only limited context per stack frame.
GDB does not have a watchdog and I don't know one from Eclipse either.
My environment is that I PuTTY into my Linux host with an Xming windowing application open on my Windows 7 system.
Then I issue a bash shell script to initialize (source) environments and additionally launch the plasma-desktop
#!/bin/sh # script for starting up login programs source /opt/intel/parallel_studio_xe_2017.0.035/bin/psxevars.sh intel64 source /opt/intel/compilers_and_libraries_2017/linux/bin/compilervars.sh intel64 source /opt/intel/itac/2017.0.020/intel64/bin/mpsvars.sh --vtune source /opt/intel/compilers_and_libraries_2017.0.098/linux/mpi/intel64/bin/mpivars.sh intel64 plasma-desktop && kwin &
this gets the builds working
But to use gdb-ia, I then have to launch a terminal window (on Linux), and reissue the compilervars.sh, then from that window, launch Eclipse.
Initially I used just the psxevars.sh, but then MPI wouldn't compile (this was on PS XE 16, haven't tried on PS XE 17)
I'd say, that opening a new terminal in your setup does not inherit the environment from the shell you started your window manager from. Otherwise sourcing psxevars.sh would have made available everything. However, I don't have that setup here and cannot check it - but you can.
It depends on your installation whether the Intel MPI library was installed with Intel Parallel Studio XE. If so, psxevars.sh should also source the paths for MPI. If you use an older Intel MPI library from another installation, then you need to source the mpivars.sh from there manually.
On the initial PuTTY into the system, the console session has no desktop. I issue the above bash shell which establishes the Intel PS XE environment then launches an instance of the plasma-desktop, which in turn inherits the environment of its parent. The bash shell completes, but with the child processes (plasma-desktop and kwin) but the PuTTY session on remote system is no longer used. It is hidden beneath desktop on the Xming window on the remote system. Or I should say it becomes hidden once I set focus to the Xming window. Now then, when I use the plasma-desktop to launch a terminal window, the terminal window (on/inside the plasma-desktop) has the environment set for Intel PS XE. Builds work without re-issuing the source commands (this includes MPI builds). It is just that the debugger doesn't find the necessary paths.
The point of sourcing prior to launch of plasma-desktop is to not have to do it every time I launch a terminal window.
This isn't a show stopper, it is just an annoying quirk.
What do you mean by "It is just that the debugger doesn't find the necessary paths."? What paths are missing?
Apparently in your setup the environment gets inherited: the compiler and libraries are found and you can start the debugger with "gdb-ia". So, what does not work? What are the exact error messages?
Does the build application run w/o the debugger?
After preparing a rather length reply, and looking at the export listings, it became apparent to me that my script, issuing lines I though unnecessary for posting to the forum, was clobbering the (Intel) sourced LD_LIBRARY_PATH. I was setting the value instead of appending the additional path.