User forums > Using Code::Blocks
SIGFPE crash when debug Excel dll
oBFusCATed:
No idea what is ArrayVisualizer.
To view custom types you need to write python printers for gdb. For more info inspect gdb's documentation.
DrOli:
Found a new SIGFPE pathology/crash, but before that I thought a short response to the previous might be helpful.
1) Array "watch issues": Perhaps these are for a "wish list", but
a) Personally, I don't think it makes sense for the Watch window entries to be immediately attempted to be filled with the entire array. Instead, those watch "rows" could simply have a "button", and only on clicking the button should and "array view" be presented.
b) The Watch list "hover windows" are much too intrusive. Is there a way to turn those off?
c) "Tools": Is there a way for the Tools/Configure Tools/Add dialogue also to include "tags" for "selected variables". For example, in addition to ${PROJECTFILENAME} etc, there might be ${CURRENTSELECTEDVARIABLE}, or whatever? Then, an array var could be selected during debug, and a Tool launched that takes that var's contents as input (e.g. then could send an array to ArrayVisualizer, having been added as a Tool, etc).
This would go a long way to solving issues with "watching" arrays, even large ones.
2) New pathology: User Defined Type (UDT) with Allocatable Array.
CB crashes the debug/watch/breakpoints process when a subroutine has a UDT that includes Allocatable arrays (CB itself does not crash, just the "process/Excel/DLL" etc with SIGFPE reported.
... CRUCIALLY, the programme actually runs in both debug and release mode, it is ONLY during watch/breakpoint that the crash occurs, and so it may be related to the "issues" with how the watch window(s) deal with arrays.
... CRUCIALLY, the UDT need NOT actually even be used (explicitly) in the code, only declared in the code. For example, an abridged over simplified version of my code is:
Module UDTSMod
Type UDTFixdArrType
Integer :: i
Real(DP) :: ArrayFxd(100)
End Type UDTFixdArrType
Type UDTAllocArrType
Integer :: i
Real(DP), Allocatable :: ArrayAlloc(:) ! this is supposed to be "(" ":" ")", but the Forum interface converts the array syntax into a "smily emoticon"
End Type UDTAllocArrType
End Module UDTSMod
... in another Module
Subroutine SR1(iErr)
!
Use UDTSMod, Only: UDTFixdArrType, UDTAllocArrType
!
!
Integer, Intent(Out) :: iErr
!
! Locals
! ------
!
Type(UDTFixdArrType) :: UDTFixdArr
!
Type(UDTAllocArrType) :: UDTAllocArr ! JUST DECLARING THIS in the s/r crashes the debug during break/watch (but works in pure "run" debug/release)
! if I comment this line out, the watch/breakpoint process works.
!
!
!
iErr = 0 ! 1st executable line: setting a breakpoint here is never reached, since the process (Excel/DLL) crashes etc.
!
End Subroutine SR1
As always, your assistance would be greatly appreciated.
oBFusCATed:
--- Quote from: DrOli on March 23, 2016, 04:05:10 pm ---a) Personally, I don't think it makes sense for the Watch window entries to be immediately attempted to be filled with the entire array. Instead, those watch "rows" could simply have a "button", and only on clicking the button should and "array view" be presented.
b) The Watch list "hover windows" are much too intrusive. Is there a way to turn those off?
c) "Tools": Is there a way for the Tools/Configure Tools/Add dialogue also to include "tags" for "selected variables". For example, in addition to ${PROJECTFILENAME} etc, there might be ${CURRENTSELECTEDVARIABLE}, or whatever? Then, an array var could be selected during debug, and a Tool launched that takes that var's contents as input (e.g. then could send an array to ArrayVisualizer, having been added as a Tool, etc).
--- End quote ---
a). Nope it won't solve it. BTW this is already available - right click -> auto update and right click -> update.
b). Settings -> Debugger -> Evaluate expressions
c). It won't help with performance, because the slow part is not the ui, but communicating with gdb.
--- Quote from: DrOli on March 23, 2016, 04:05:10 pm ---2) New pathology: User Defined Type (UDT) with Allocatable Array.
--- End quote ---
I can't do anything until I have a simple program that causes cb to crash. Sorry.
DrOli:
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 :-)
oBFusCATed:
--- Quote from: DrOli on March 28, 2016, 02:52:45 pm ---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.
--- End quote ---
OK, This one cannot be disabled.
--- Quote from: DrOli on March 28, 2016, 02:52:45 pm ---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).
--- End quote ---
As I've said use gdb pretty printers to start your array visualizer. I don't intend to add a feature that allows a tool to take the output of the debugger and pass it to some other executable. Also keep in mind that the length of the command line string is limited on most oses (32kb on some).
The rest TL;DR; sorry...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version