Well, have made some progress, though some of it seems to be in a very wrong direction ... and it may be a bug in gdb, see below.
First, wrt the "watch issues" from earlier
b) I am not sure if we are speaking about the same thing. I have always had -> Evaluate Expressions "off", so there is NO "hover" etc wrt items in the "code listing" during debug.
Rather, I am speaking about the "watch window" itself, where "hover" over items in the watch list cause a "pop up", and that is what I wish to turn off.
c) Again, not sure if we are speaking about the same thing. I have attached some Tools to CB. One of those tools is a special text editor (KEdit), and that works as expected with the available "tags" (e.g. ${Target}, etc.).
I have also attached the ArrayVisualizer (AV) as a Tool. However, it needs to be given a connection (like with the KEdit), but in this case, the connection needs a "tag" of the currently selected variable in the listing during debug. That is, AV needs to be launched with the "contents" of the variable sent to it, so it can display the values.
That is the sort of "tag" I could not find in the Tools setup (e.g. not sure what that would be, but something like ${CURRENTSELECTEDVARIABLE} or whatever).
Related to this is the question of "symbol browser", and which doesn't work with Fortran, plus has various other issues. I don't actually need a full whack "symbol browser". All I really need is a tool that lists all of the Subroutines/Functions in the current file, and, ideally, allows me to double click on an entry to navigate to that sub-programme. I have started to look at "script" and "plug-ins", but I fear I have a substantial learning curve ahead of me. Any directions/suggestions would be appreciated.
Second, though more on this below, I have updated my GCC/GDB/MingW etc installation from 4.9.2/7.9 to 5.3.0/7.10.1. This has helped with (much) improving the DLL/Debug stability (e.g. now can set breakpoints prior to debug without crashing the process). Save for other issues below, it would be my strong recommendations for other CB/Fortran users to consider the leap to 5.3.0/7.10.1.
However, a weird thing has occurred, and I am not sure why. Now, when I compile etc, the listing of warnings/errors etc appears as usual in the messages, but now clicking on a warning/error in the build messages window etc NO LONGER navigates the screen to the offending line. That is, I must "manually" go and navigate/find the file/line that is named in the warning/error.
I have had a look at the Global Compiler/Other/Advanced/Output Parser. I tested some of the lines from message log, but the tests produced no results (i.e. the test results dialog pops with "empty" fileds for "file" etc.
... any thoughts on how to get back the "click/navigate" feature?
I have a vague recollection that GCC530 now provides "enhanced" return messages (e.g. with "colours" etc.), not sure if something therein is interfering with the process.
ASIDE: since GCC 5.x.x, the Fortran -Wtabs and -Wno-tabs switches have been "reversed", so now one needs -Wno-tabs to obviate the "non-conforming tab" warning etc (whereas previously one used -Wtabs to obviate the warning) ... other "switch" issues have also come to ligth in the newer versions.
Fourth: "the Crashes" - recalling that I am debugging a Fortran/DLL/Excel addin process, it looks as if things are worse than previously imagined. I have now completed a range of additional experiments, including also with NetBeans and the exact same GCC etc that I use with CB, and also with CVF/IVF/VisualStudio (to see if it's the IDE, or "GNU/GCC/GDB", or
etc).
The problem does NOT occur with CVF/IVF etc, but it does behave/crash exactly the same way in NetBeans. So, it seems clear it is not an IDE issue.
The GDB logs definitely state there is an "internal error" with GDB (virtual memory exceeded, etc., you are welcome to copies of those if you like). CB returns a GDB error 1, while Netbeans returns a GDB error 3, but the logs general complain about virtual memory exceeded. Sometimes (not sure why) the logs actually state more details, like
"internal-error: virtual memory exhausted: can't allocate 872948320 bytes.\nA problem internal to GDB has been detected"
Just in case, I have set my stack size to 1Gig for testing, no joy. Presumably GDB's mem settings must be set by different means, or may not be the real issue anyway.
I performed these test with both 4.9.2/7.9 and 5.3.0/7.11 ... pretty much the same result/crash in both cases.
I did some checking on the web and the GDB bug reports, and they seem to have had this type of issue in the past, but the exact circumstances of those bugs don't induce the crash here (I wrote some test code to double check).
I guess I will file a bug report with GDB if I can produce a "practical" distributable test code ... which may not be all that easy, see below.
Regarding providing "test code":
1) The code that causes the crash is a collection of "bits", since one needs not just the Fortran code, but also the xls, xla, etc, and one needs to have some idea how to install/link/register all that at their end to perform the test.
2) I cannot tell what exactly is causing the problem, not even in "general" terms. Earlier tests implied that it was in connection with User Defined vars including Allocatable arrays, but tests since suggest that cannot be the exact/specific or only issue (though may still play a role somehow).
3) I have performed many experiments, and very often there is no reason or rhyme to the crash. Even when I can isolate the exact line that is "causing" the GDB bug/crash, it often does not make any sense. For example, in an s/r with several Optional Args, when using If(Present()) then, many of the Optional Args work as expected, but then one of them will cause the crash. By "causing the crash", I mean that often the debugger cannot even entre the s/r. Commenting out the offending line(s) (determined by tedious trial/error) prevents the crash, but then I am missing Arg's/functionality from from my s/r etc.
There are many different s/r's where the debugger cannot enter without the "internal memory exceeded" bug, all of those s/r's have different properties ... and so, there appears no (simple) reason or rhyme, at least at this time.
I fear at this rate, the amount of time spent "fighting with GDB" may prevent moving from CVF/IVF to gFortran ... but I'll plod on a little yet.
I appreciate much of this may be well outside CB's remit ... still any hints, directions, etc would be much appreciated ... I am willing to take on some extra "work" to help the process along :-)
