Debugging Fortran on Linux

[Paul Anton Letnes]

Hi!

I'm (still) working on an old legacy code, to much bewilderment and
confusion. I've used Visual Studio as a GUI debugger on Windows, and
experimented with several others on Linux: Qt creator (no true Fortran
awareness), Eclipse (a lot of NullPointerExceptions; seems like there's
something about my project that photran doesn't like) and PGI's debugger
(a sad story). So my question is - is there a Fortran-aware debugger
that's graphical (so I get a better overview than with gdb in the
terminal) and doesn't give me NullPointerExceptions or cryptic errors?

I've found qtcreator to be not too bad, but it seems very much geared
towards C++, so there's some Fortran concepts it doesn't quite understand.

I build my code with the Intel compiler (and GNU and NAG, too, but the
code always crashes due to some bug that I don't have time to fix yet)
and use the gdb-ia debugger in the terminal and in qtcreator.

Cheers
Paul

[Stansfield Temmelmeier]

You could try Solaris Studio. The Fortran is quite good if still behind
Intel in 2003 and later support but there is a gui for dbx debugger Fortran
aware and very nice. I did have some weird problems on Linux in previous
version when SPARC version worked perfectly but I can't remember if it's
related to processing of Fortran. I think it's good to try this also because
it's another choice in compilers to help you diagnose bugs, standards
compliance etc.

Another choice is Netbeans using gfortran because Netbeans provides
reasonable GUI debug support for gfortran if you have proper level of gdb to
match your gfortran. gdb is not difficult to compile later versions on Linux.

Stan

[Stefano Zaghi]

Dear Paul,

if you are using Intel Fortran compiler on GNU/Linux, you should have also idb, the Intel debugger (and maybe other useful tool like inspector, vtune...).

I am not a fan of GUI debugger (indeed of debuggers at all... vim is enough :-), but for working with some of my colleagues I found idb a very good visual Fortran debugger.

Eclipse is to heavy in my opinion while Kdebug was not so bad. In the commercial field I have occasionally used Totalview (for large parallel-clusters application) it being good for debug parallel applications.

My best regards.

[themos...@gmail.com]

Hello Paul,

Since you've used the NAG compiler, have you tried the (Fortran-aware) dbx90 debugger that comes with it? For code crashes, the compiler options -C=<options> (enable runtime checks) and -gline (produce traceback for runtime errors) have been helpful.

Themos Tsikas, NAG Ltd.

[Paul Anton Letnes]

Thanks for the tip. No, my code just crashes if I run the nag-built
executable. Yes, I know this indicates a serious bug. No, I don't know
how to fix it in a reasonable amount of time. Yeah, there's more than
one bug... I'm quite pleased I managed to improve the syntax enough that
the code compiles under NAG.

Cheers
Paul

[Paul Anton Letnes]

I'm compiling on gfortran but the generated executable just crashes.
Same story as with NAG (ref. other post here).

We're using a few Fortran 2008 features and I'm not inclined to further
increase the compiler count... MAybe in some distant future.

Paul.

[Wolfgang Kilian]

I may add that on Linux, I use nagfor with the said options -C=all
-gline. This also works nicely with gdb - at least, I use gdb to
inspect core files, if the runtime traceback is not helpful.

(I remember that there was an issue with dbx90 not completely
understanding the new F2003 features of nagfor, but this is a long time
ago, so it may not be relevant anymore.)

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Paul Anton Letnes]

Stefano,

I do agree that vim is the superior editor. I use it for virtually
everything, but it's not helpful with actually debugging the code. Some
times, that's useful.

idb seems to be deprecated so it's not really an option. It's not in my
Intel 2015 installation. What a shame!

Totalview we can't afford. Maybe Kdebug is a possibility?

Cheers
Paul

[Arjen Markus]

It seems to me that the first thing to do is find out where the crash occurs. You can simply run the program via the GNU debugger, gdb. It has a command interface, so you will need to learn a few commands:
- run the program
- list the traceback to see where the problem became manifest
- print variables for further inspection

That is easy enough. If the bug does not occur within the context of the debugger, then a graphical debugger would not help either. It is back to the print statements in that case.

GUIs are useful but they are definitely not the only way to use an interactive debugger.

Regards,

Arjen

[Stefano Zaghi]

>
> Stefano,
> ...

> idb seems to be deprecated so it's not really an option. It's not in my
> Intel 2015 installation. What a shame!
>

Wow! It was 2012 the last time I used it with my boss... I checked in my 2015 installation and there is no idb, only a custom gdb! In some sense I happy of the decision of Intel: it seems that they have planned to improve gdb, rather than reinvent the wheel. On the contrary I am sorry for you, because idb was nice for whom want a GUI.

> Totalview we can't afford. Maybe Kdebug is a possibility?
>

I remember that kdebug had a nice GUI, but I used it on the same period of 2012, thus my feedback could be wrong. In case I think that you can use the present gdb-ia custom intel version as back-end with kdebug as GUI.

OT: Paul asked just for a GUI debugger, not on how it is better to develop his codes.

If we go off topic I can say that in my opinion debuggers are not much attractive at all, "vim+print" is better for me because I spent all my development-life into the terminal, but other people like Paul prefer a GUI...

[Paul Anton Letnes]

Well no, I don't prefer a GUI. However, when the subroutines have 50
arguments and I don't know which ones are important yet, I find a
debugger helpful, and a terminal debugger a bit unwieldy.

I do most of my work with vim, zsh, cmake, make and the like. Much like
you, Stefano, from I gather.

Oh, and I suspect IDB was "just" a frontend to GDB before as well.
That's a guess, though.

Paul.

[Stefano Zaghi]

Il giorno venerdì 11 settembre 2015 11:53:29 UTC+2, Paul Anton Letnes ha scritto:

>
> Well no, I don't prefer a GUI. However, when the subroutines have 50
> arguments and I don't know which ones are important yet, I find a
> debugger helpful, and a terminal debugger a bit unwieldy.
>
> I do most of my work with vim, zsh, cmake, make and the like. Much like
> you, Stefano, from I gather.
>

Oh yes, I was meaning for this specific problem not in general, I am sorry.

> Oh, and I suspect IDB was "just" a frontend to GDB before as well.
> That's a guess, though.
>

Yes, I also think so, nevertheless that front-end was nice.

Another gdb front-end widely used is DDD, http://www.gnu.org/software/ddd/

Good luck Paul!

[Stefano Zaghi]

A modern front-end could be this

https://github.com/sirnewton01/godbg

that is a web based one.

[Stefano Zaghi]

Another well known gdb front-end is insight

https://github.com/monnerat/insight

[Paul Anton Letnes]

No commits for 2 years. Not too promising?

[Paul Anton Letnes]

Wow, someone had a lot of time to create GUI frontends... I am amazed.

[Stansfield Temmelmeier]

On 2015-09-11, Stefano Zaghi <stefan...@gmail.com> wrote:

Used to be very nice in days of 32 bit Linux but is now broken and long
unmaintained don't go there.

Stan

[robin....@gmail.com]

huh?

Then get onto it.
Why are you wasting our time complaining about it.
NAG and other compilers have switches that you can activate
for them to carry out essential checks,
such as subscript errors, uninitialized variables, etc. etc.

[Stefano Zaghi]

Il giorno venerdì 11 settembre 2015 14:41:42 UTC+2, robin....@gmail.com ha scritto:
> huh?
>
> Then get onto it.
> Why are you wasting our time complaining about it.
> NAG and other compilers have switches that you can activate
> for them to carry out essential checks,
> such as subscript errors, uninitialized variables, etc. etc.

I am sure that Paul knows how to compile his code in "bullet-proof" mode for activating all checks, warns, debugs... his original OP asked for a suggestion on a graphical debugger, why are complaining about this?

[FortranFan]

Have you looked into Code::Blocks?
http://www.codeblocks.org/home

and its FortranProject plug-in:
http://sourceforge.net/projects/fortranproject/

Their newsgroup is very good to get answers:
https://groups.google.com/forum/#!forum/cbfortran

And notice in above how Code::Blocks and its Fortran plug-in can work with different toolchains such as gfortran and Intel Fortran.

Contrary to some responses, I find GUI-based debuggers to be a necessary tool while working with code. I'd say there is no glory in hacking without it. Visual Studio, for example, saves me so much time, it's quite prudent to use it for Windows programming. To me, GUI debuggers embody the adage, "a picture is worth a thousand words." So you're right in pursuing this, hopefully something will work out for you.

[Gordon Sande]

Some time ago I found the debugger in Salford FTN95 (now Silverfrost) to be
much more Fortran oriented than the several machine language debuggers I had
previously used. And the other features make use of the debugger less likely.

Now you will complain that FTN95 is for Windows and does not work under Linux.
I beleive that you can run Windows in a virtual machine under Linux if you have
a copy of Windows. They a pretty cheap for the entry version. Or you can use
one of the Windows emulators, most are based on Wine, to avoid the MS
licensing.
I have no idea if FTN95 works under Wine. Or just borrow somebody's
Windows box.

FTN95 is intended to stand up to student debugging so is pretty robust. You
will have to figure out the cost of your time in Linux, your time under FTN95
and how much time and attention it would cost to be able to use FTN95. All the
costs will be other than their nomical values because of the joys of large
organizations.

[Stefano Zaghi]

Il giorno venerdì 11 settembre 2015 15:00:45 UTC+2, FortranFan ha scritto:

> Have you looked into Code::Blocks?
> http://www.codeblocks.org/home

I also vote for Code::Blocks. I used it some years ago and it was very nice.

> Contrary to some responses, I find GUI-based debuggers to be a necessary tool while working with code. I'd say there is no glory in hacking without it.

It is not a matter of Glory. I just think that anything that obligates me to go out the terminal and use the mouse makes my workflow slow... for the same reason I am working without a Desktop Environment with only a tiling window manager (i3, very very nice). Really I feel I am more productive in terminal rather into a GUI window.

[baf]

The Salford debugger is pretty good, but the compiler does not support
much beyond Fortran 95 and the OP is using more recent Fortran features.
I have used the debugger in Code:blocks with the Fortran plugin under
Linux and it works pretty well.

[Ron Shepard]

On 9/11/15 1:45 AM, Paul Anton Letnes wrote:
> So my question is - is there a Fortran-aware debugger that's graphical
> (so I get a better overview than with gdb in the terminal) and doesn't
> give me NullPointerExceptions or cryptic errors?

It has been a while since I've used it, but ABSOFT has a nice gui
debugger that works with its compiler.

$.02 -Ron Shepard

[robin....@gmail.com]

Because he's running around in a china shop.
He says he hasn't got time to fix it (the reason for crashing).

The first thing he needs to do is to compile each procedure
separately until each is free of bugs;
then take the main program and add one called subroutine, and test that,
with debug options enabled, etc.
Then add another called subroutine, and test that, and so on.

BTW, the last thing he needs is a graphical debugger.

[Stefano Zaghi]

>Because he's running around in a china shop.
He says he hasn't got time to fix it (the reason for crashing).

>The first thing he needs to do is to compile each procedure
separately until each is free of bugs;
then take the main program and add one called subroutine, and test that,
with debug options enabled, etc.
Then add another called subroutine, and test that, and so on.

>BTW, the last thing he needs is a graphical debugger.

My English is bad, thus I could be wrong, but Paul asked "can you suggest me a graphical debugger tailored to fortran?", now you replay with unuseful hints for solving bugs of which you do not know anything. If you (like me) think that a graphical debugger is unuseful, this is a valid opinion, but not in topic with what Paul asked for. Your post sound very snooty to me.

My best regards.

[Richard Maine]

Stefano Zaghi <stefan...@gmail.com> wrote:

> My English is bad, thus I could be wrong, but Paul asked "can you suggest
> me a graphical debugger tailored to fortran?", now you replay with
> unuseful hints for solving bugs of which you do not know anything. If
> you (like me) think that a graphical debugger is unuseful, this is a
> valid opinion, but not in topic with what Paul asked for. Your post
> sound very snooty to me.

Robin's post sounded to me very much like many of his posts. I carefully
refrain from saying whether this is complimentary or not. :-) Draw your
own conclusions.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[FortranFan]

On Friday, September 11, 2015 at 9:10:04 AM UTC-4, Stefano Zaghi wrote:

> ..

>
> It is not a matter of Glory. I just think that anything that obligates me to go out the terminal and use the mouse makes my workflow slow... for the same reason I am working without a Desktop Environment with only a tiling window manager (i3, very very nice). Really I feel I am more productive in terminal rather into a GUI window.

Your comments remind me of this guy:
http://www.ispot.tv/ad/7K7e/kayak-lecture

[lyng...@gmail.com]

DDD is a graphical front end to gdb.

[Stefano Zaghi]

>>>Your comments remind me of this guy:
http://www.ispot.tv/ad/7K7e/kayak-lecture

I take this like a compliment... while you set breakpoints with your handy mouse, I have already debugged my codes by vim :-)

The world is wonderful due to its variety, 100 programmers => 100 different preferred editors :-)

See you soon

[fj]

No, I don't think so. idb was much better than GDB for debugging F95 codes. A correct F95 GDB interface is still not included in the main development line of GDB. This is why INTEL provides now its own version of GDB. But this one is difficult to get without buying the INTEL compiler...
>
> Paul.

[Stefano Zaghi]

In the middle-earth between GUI and terminal based debuggers, I found an interesting project:

https://github.com/cyrus-and/gdb-dashboard

I have not tested it, but it seems very interesting. Later today, I will probably give it a chance. Maybe it requires a superficial python knowledge.

My best regards.