SIGFPE crash when debug Excel dll

[DrOli]

I have set the Project "programmes arguments" so that on debug the current code (which is a Fortran DLL/Excel Add In) first launches Excel, and a particular XLS file that relies on the source Fortran loaded in C::B.

On clicking the Debug process (red arrow/triangle), the debug appears to begin, it starts to launch Excel, however it crashes before Excel completes its launch.  The Crash is a SIGFPE (arithmetic fault) raised be kernel32.dll, following msvbvm60.dll.

This exact some process works correctly when the dll/debug is launched from any of CVF/Intel/VisualStudio etc.

To be clear, it never makes it back to C::B or any lines in the source.

I have tried it with a couple specific xls's, and also without any xls, just Excel on its own.  Always the same crash, at the same point.

I would be grateful for any assistance as without this facility the entire C::B/GCC/MingW strategy is shot ... and I would like to move away from the commercial compilers.

[BlueHazzard]

This is probably a problem with gdb...

you can try to update gdb, or use CDB instead

you can try to run excel trought gdb without c::b, if this works, it would be great if you can post the output from gdb...

[oBFusCATed]

Another option is to use the Debug -> Attach instead of starting Excel under gdb control.

[DrOli]

OK, I tried CDB vs GDB, as well as all of the permutation of the GDB's (Default, i686, x86) etc. ... NO JOY.  It always crashes CB/MingW etc in exactly the same way.

I tried the "attach" route also, but after entering the PID, and saving etc, on trying to run it told me that I must choose a PID, and on checking the previously entered PID had disappeared ... I repeated this a few times, always with the same results, again NO JOY.

Once again, and from earlier, when I do this same process with Visual Studio/CVF/IVF etc, it always works (Excel launches from the debugger, and activating DLL Funcs in sheets etc causes entry back into the IDE/source).

Also, on an earlier (non-DLL) project,  I had tested CB/MingW with "console/GUI" code, where debugging worked, more or less ... so it may be something special in relation to DLL's/Excel etc ... but no idea really.

A few other really weird things are noticeable.  For example, the DLL works in Debug compile mode (not running gdb), but Excel crashes with the Release mode of the exact same DLL as soon as one of that DLL's funcs is attempted to be calc'd.

By contrast, both Debug and Release formats from VS etc work as expected.

This is all on WinXP64, using the 32bit MingW64 4.9.1 machinery with gdb 7.81.

... I am a little apprehensive about updating MingW etc, since I had used that to build GTK etc etc, which was very difficult due to the many version collisions/issues ... so I'd rather not have to install a new MingW etc, and the lose some months getting everything else to work.

I attach the CB (crash) log:

Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: E:\FORTRAN\Climate\Hitran1\
Adding source dir: E:\FORTRAN\
Adding file: D:\Apps\MSO\Office10\EXCEL.EXE
Changing directory to: E:/FORTRAN/Climate/Hitran1/.
Set variable: PATH=.:\Apps\MingW\mingw32\bin;D:\Apps\MingW\mingw32;C:\Documents and Settings\All Users\Application Data\Oracle\Java\javapath;D:\Apps\Winteracter\bin;d:\Apps\MsDev\Common\TOOLS;d:\Apps\MsDev\Common\MSDEV98\BIN;d:\Apps\MsDev\DF98\BIN;d:\Apps\MsDev\VC98\BIN;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program Files (x86)\ART\ARTLibXL;C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn;C:\Program Files\Microsoft SQL Server\90\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn;D:\Apps\GhostScript\gs\gs9.10\lib;D:\Utilities\Universal Extractor;D:\Apps\Intel\IDB\9.1\IA32\Script;D:\Apps\Intel\Compiler\Fortran\9.1\IA32\Bin;D:\Apps\Intel\Compiler\Fortran\9.1\em64t\bin;D:\Apps\Intel\IDB\9.1\EM64T\Script;D:\Apps\AMD\CodeAnalyst\bin;C:\Program Files (x86)\AMD\CodeAnalyst\bin;D:\Apps\MingW\local32\bin;D:\Apps\MingW\msys\1.0\bin;D:\Apps\CMake\bin
Starting debugger: D:\Apps\MingW\mingw32\bin\gdb.exe -nx -fullname  -quiet  -args D:/Apps/MSO/Office10/EXCEL.EXE
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from D:/Apps/MSO/Office10/EXCEL.EXE...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 7.8.1
Child process PID: 192
Program received signal SIGFPE, Arithmetic exception.
In RaiseException () (C:\WINDOWS\syswow64\kernel32.dll)


By contrast, a comparable (successful) Log from VS is:

Loaded 'D:\Apps\MSO\Office10\EXCEL.EXE', no matching symbolic information found.
Loaded 'not_an_image', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\ntdll32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\kernel32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\advapi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\rpcrt4.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\secur32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\gdi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\user32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\ole32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msvcrt.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\shimeng.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\apphelp.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\AppPatch\acgenral.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\shlwapi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\winmm.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\oleaut32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msacm32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\version.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\shell32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\userenv.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\uxtheme.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\imm32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\WinSxS\wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll', no matching symbolic information found.
Loaded 'C:\Program Files (x86)\Common Files\Microsoft Shared\Office10\MSO.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msctf.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msctfime.ime', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\ctagent.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\clbcatq.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\comres.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msimtf.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\xpsp2res.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\setupapi.dll', no matching symbolic information found.
Loaded 'D:\Apps\MSO\Office10\Library\Analysis\ANALYS32.XLL', no matching symbolic information found.
Loaded 'D:\Apps\MSO\Office10\Xlcall32.dll', no matching symbolic information found.
Loaded 'C:\Program Files (x86)\Common Files\Microsoft Shared\Office10\RICHED20.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\sxs.dll', no matching symbolic information found.
Loaded 'C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL', no matching symbolic information found.
Loaded 'C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA6\1033\VBE6INTL.DLL', no matching symbolic information found.
Loaded 'D:\Apps\Adobe\Acrobat 9.0\PDFMaker\Office\PDFMOfficeAddin.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86\msvcp80.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86\msvcr80.dll', no matching symbolic information found.
Loaded 'D:\Utilities\SnagIt 7\SnagItOfficeAddin.dll', no matching symbolic information found.
Loaded 'D:\Utilities\SnagIt 7\SnagItOfficeAddinRes.dll', no matching symbolic information found.
Loaded 'D:\Utilities\SnagIt 7\msvcr71.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.5190_x-ww_D21E1F39\comctl32.dll', no matching symbolic information found.
Loaded 'D:\XL AddIns\CodeCleaner\VBACodeCleaner.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msvbvm60.dll', no matching symbolic information found.
Loaded 'C:\Program Files (x86)\Common Files\Designer\MSADDNDR.DLL', no matching symbolic information found.
First-chance exception in EXCEL.EXE (KERNEL32.DLL): 0xC000008F: Float Inexact Result.
First-chance exception in EXCEL.EXE (KERNEL32.DLL): 0xC000008F: Float Inexact Result.
First-chance exception in EXCEL.EXE (KERNEL32.DLL): 0xC000008F: Float Inexact Result.
Loaded 'D:\Apps\Adobe\Acrobat 9.0\Acrobat\Adist.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\winspool.drv', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\comdlg32.dll', no matching symbolic information found.
Loaded 'D:\Apps\Adobe\Acrobat 9.0\Acrobat\Adist.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\winspool.drv', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\comdlg32.dll', no matching symbolic information found.
Loaded 'D:\Apps\Adobe\Acrobat 9.0\Acrobat\Adist.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\winspool.drv', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\comdlg32.dll', no matching symbolic information found.
Loaded 'E:\C Work\ARTLibXLCore\CallerDims.xll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\oleacc.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\FM20.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\comdlg32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\linkinfo.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\ntshrui.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\netapi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\FM20ENU.DLL', no matching symbolic information found.
Loaded 'D:\Apps\MSO\OFFICE11\REFEDIT.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\asycfilt.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\wintrust.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\crypt32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msasn1.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\imagehlp.dll', no matching symbolic information found.
The thread 0x744 has exited with code 1 (0x1).
Loaded 'E:\FORTRAN\ARTLibXLCore\Add-In\ARTLibXLCore.xll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\mfc71d.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\msvcr71d.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\MFC71ENU.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\wininet.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\normaliz.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\urlmon.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\iertutil.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\iphlpapi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\psapi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\ws2_32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\ws2help.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\DFORMDD.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\MSVCRTD.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\wsock32.dll', no matching symbolic information found.
Loaded 'E:\FORTRAN\ARTLibXLCore\Add-In\FuncNmXL.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\mlang.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SysWOW64\hlink.dll', no matching symbolic information found.

... this too has a "float inexact" error, but seems to survive it somehow, and works.

[DrOli]

I have also found a win binary of gdb ver 7.9 ... exactly the same results with that too.

[oBFusCATed]

I tried the "attach" route also, but after entering the PID, and saving etc, on trying to run it told me that I must choose a PID, and on checking the previously entered PID had disappeared ... I repeated this a few times, always with the same results, again NO JOY.

What do you mean by this?
The steps are:
1. start excel
2. find the pid of excel
3. debug -> attach
4. enter the pid of excel

For the record the debug format of gcc/gdb is different than the one used by visual studio, also I'm not sure if it follows the abi 100%.
So I'm not surprised that you have these problems.
Also what do you mean by cdb doesn't work? Can you show a log from it?

[DrOli]

1) Re "attach": those were the steps I followed, not sure why it did not work earlier,  it does now :-).

Though, it is a bit of a pain to fiddle with those setting every time a debug is required.

If I had to guess, the previous attempts failed to due the multiplicities of DLL's I am running and they may have had some "cross contamination" (that's a long story).

2) CDB:  I enter the Setting/Debugger bit, and change the radio button from GDB to CDB.  Not sure if that is the correct procedure.

... BTW, I now running GDB 7.9.0

I have attached a couple of images Re the "parameters" approach, showing the messages just after the SEGFPE "balloon".

3) Also some good news, the earlier comment Re Debug compile executing, but Release crashing, has also been resolved (I tried to get a little too clever with the directives/switches for "decorating" the export symbols (notably -mrtd), and that seemed to be the cause of that (along with a little extra stupidity of mine with some OpenMP directives).

Finally, and I hope it is not too cheeky to ask on an unrelated point, but one little thing that is very annoying is that the copy/paste etc access via the "right-click flying menu" is rather distracting, being buried in a sub-menu.  Would there be instructions somewhere to have CB show more typical layout, with the copy/paste etc items on the "top" rather than a sub-menu?

BTW, I am very grateful for your prompt and thoughtful attention ... many thanks.

[oBFusCATed]

Have you tried to hit the continue button after getting the SIGFPE?
Have you tried to disable catching of exceptions in the settings of the debugger?

[DrOli]

1) "Continue":  Yes, I always try that.  Just get more SIGFPE "balloons", repeat of same messages in logs,  etc.

2) "Catch Exceptions":  The only thing I found like that was "catch C++ exceptions".  Tried it, no joy.

Cheers for that ...


... BTW, in Project/Programme Args etc.  Presumably, the actual "Program Arguments" field takes the path/file-name of the xls, or whatever, that should be opened by the program (path/app) in the "Host Application" field.  Are there any syntax requirements for the "file-name" etc, such quotes, no blank spaces, "reverse slash" for paths,  etc?   It may not affect the issue here (since I've tried also no file, as well as various permutations), still it's best to know.

[DrOli]

FYI, have just dloaded/installed the just released CB 16.  It also fails with SIGFPE exactly as before when attempting to do debug Excel/DLL's etc.

BTW, on a separate note, and I hope this is not too cheeky, I am trying to get some sort of listing/display to show up in a View or Toolbar that shows all the Subroutines/Functions in the currently displayed file (all Fortran 90/95 etc, usually Modules).  Ideal also to be able to navigate between them, etc.  I wasn't sure if that would be the job of the "Symbol Browser" (it did not work for me) or .  Is there such a feature in CB?  How is it launched?  ... Perhaps there is a post for this.

[BlueHazzard]

FYI, have just dloaded/installed the just released CB 16.  It also fails with SIGFPE exactly as before when attempting to do debug Excel/DLL's etc.

As i mentioned i don't think that this is a problem of codeblocks, but a problem with gdb and how it handles signals. So i would recommend you to search help in a gdb forum, or on the gdb mailing list. They can help you more.
You may also look at this:
http://stackoverflow.com/questions/15662810/gdb-catching-a-signal-and-continue-debugging
https://www.gnu.org/software/gsl/manual/html_node/Handling-floating-point-exceptions.html
http://fpc-devel.freepascal.narkive.com/klJ6iOWq/hot-to-handle-sigfpe-sigsegv-using-gdb-as-debugger

BTW, on a separate note, and I hope this is not too cheeky, I am trying to get some sort of listing/display to show up in a View or Toolbar that shows all the Subroutines/Functions in the currently displayed file (all Fortran 90/95 etc, usually Modules).  Ideal also to be able to navigate between them, etc.  I wasn't sure if that would be the job of the "Symbol Browser" (it did not work for me) or .  Is there such a feature in CB?  How is it launched?  ... Perhaps there is a post for this.

This is the code completition plugin (with the symbols tab as you have found), and should work. Have you checked if the right "View" is selected (in the symbol tab is a drop down menu)? At least it works with c/c++ i don't know if fortran has an cc that supports symbols...

greetings

[DrOli]

Many thanks for that, it was helpful, and have made at least some progress:

1) SIGFPE:  the 2nd link you had kindly provided inspired a guess (I am "math geek" not an "IT geek", so some of this is in the "nether regions" for me).  Notably, I put the expression

handle SIGFPE nostop

into the Settings/Debugger "Debugger Initialization commands" field, for each Debugger ( default/x86/i686, just in case) ... on a hunch.

This works, more or less.  CB/debugger still crashes sometimes (e.g. sometimes when a breakpoint is set), and it still throws various complaints at various times ... still, it is a massive improvement over "attach" etc.

2) Symbol Browser:  Yes I get the Symbol Browser tab/categories etc, just no symbols (with Fortran) files.  Yes, it does work with my C projects, the Symbol Browser tab shows the expected things.  This was not entirely unexpected.  For example, with older MSDev IDE's working with Fortran, one had to ask the "machine/IDE" explicitly to create a special browser file on Build, and it would produce a ".PDB" file, which then could be used with MSDev for at least some listing/navigation for Fortran. 

So, I thought there might be some "hidden switch" to create a ".PDB" equivalent in CB.

... it sounds like not, and so it seems no joy for Fortran ... perhaps this might go on a "wish list".

A couple of points:

1) Please please please, de-couple this from "code completion".  I hate code completion, I just need the symbol browser.

2) There are various times at which the CB interface "re-locates focus" (without indication)  to a portion NOT currently under the cursor.  Then, when using a mouse wheel (expecting the portion where the cursor is) to scroll, instead that "not in focus" portion scrolls.  Sometimes this is just annoying, but at other times it can become more serious.  For example, when I tested one of my C projects with the CB Symbol Browser, I scrolled the wheel while the cursor was over the "symbols", but instead CB scrolled the drop-down field which selects the scope of the symbols.  So, I had it set to "my project", and on its own, it scrolled to "everything" ... and then of course, CB when off to never-never-land for a long time while it sorted the symbols for every single bit of code in any way associated with that C project.

... I am guessing a simple solution is for CB to be a bit more diligent in checking/re-checking the cursor location and the implied "object in focus", perhaps another item for the wish list.

Once again, many many thanks for your prompt and helpful efforts.

[DrOli]

As a follow-up, it appears that the Excel/Fortran/DLL debuging process also has serious difficulties when large arrays are involved (e.g. 50 meg). 

I don't know enough to decide if this is a CB issue or a GDB issue (or ).  In short,

1) CB/GFortran/DLL debugging works with the settings discussed previously, at least for "normal" size arrays/vars

2) I have set -Wl,--stack,52800000 in the linker settings (I also use OpenMP, not sure what difference that makes to this issue, but the problems exist for both OpenMP and non-OpemMP code).

3) Everything works in Release mode, and also in Debug "run" mode, at least until I try to set break points in s/r's that pass/use large arrays etc.  Then and or all of the following occurs:

a) CB "goes off into the ether" for a very long time, sometimes crashing CB outright, sometimes crashing Excel, etc, resulting with SIGFPE

At various times, the CB GUI itself does weird things (border changes colour), and generally has the feeling of "not responding" etc.

b) I started experimenting with the array sizes.  If I set small enough arrays, all seems well.  As I increase the array sizes, trying to stop at break points becomes increasingly difficult/time consuming (with much CB cpu/mem usage "whirling and twirling").  At sufficiently small array sizes, even with difficulties, CB can eventually complete the calc (though not stopping at break points in any predictable way, as I click the continue icon).  At large enough array sizes, the full crash occurs ... sometimes requiring CB to be "end process" from TaskManager, etc.

Is there some internal limit in CB or GDB etc?  If so, how/where can that limit be changed?

Many thanks

DrO

[oBFusCATed]

Add this "set print elements 200" to the initial commands in the debugger settings and should fix the problem.

[DrOli]

Cheers, that fixed it. 

My gut suggested that it might be  a "watch window thing", and this fix appears to limit the number of items per watch window var.  Is that correct?  Does the setting do anything else?


BTW, on a related point, though I am not sure if this should be in a different thread:  I have tried to link in ArrayVisualizer (AV) for "watching" array var's during debug, but I have no idea how to link a watch var to AV (the Tools set up does not have an obvious option for this).  I have tried a few things, and did a search, but no joy.

Also, when watching vars that are of a User Defined Type, the CB watch just presents, effectively, the "flat array block representation".  Is it possible for the Watch viewer to have a "Tree" or "structure relevant"  view/format?

Many thanks

[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]

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).

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.

2) New pathology: User Defined Type (UDT) with Allocatable Array.

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]

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.

OK, This one cannot be disabled.

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).

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...

[DrOli]

Partial Response:

1) From previous "Second" point, Re the "click in message window" (e.g. on warning/error etc), CB won't navigate (I think you call it "jump") to the relevant file/line cited by the warning/error.

As I had speculated, it is definitely something to do with GCC5.3.0/GBD7.10.1.  When I point my MingW back to the older version (4.9.2/7.9), the "jumps" WORK.

No idea how to fix this in 5.3.0 (I played around with the "outparse" a bit, but it's beyond me), any thoughts would be appreciated.

BTW, at the moment, the "jumps" occur via a single click (when they work).  Is there a way to have only double-click make the "jump"?


2) GDB Crash/Bug:  I have filed a bug report Re the GDB breakpoint crashes.  I have produced an entire suite of files, CB project, Excel AddIn, etc that demonstrate the bug.  Not sure if you are interested, but I can upload those files for your attention also, if desired.

Also, even if no interest in the bug/crash testing bits, those files include a PDF with a couple sections explaining how to set-up CB for Debugging DLL's/Excel Add-Ins, etc.  It is possible that, with some edits, CB might be able to make use of those docs for the benefit of others.  Let me know.


3) Purely for fun, I had made a guess as to the meaning of your remark "TL;DR;", I wonder if you might confirm what that means?

Cheers

[tigerbeard]

3) Purely for fun, I had made a guess as to the meaning of your remark "TL;DR;", I wonder if you might confirm what that means?
Cheers

I would guess TooLong Didnt Read...

Always difficult to hit the balance between giving enough details vs. wast peoples time. Having the problem all the time...

[DrOli]

Cheers for that.

Re the "no jump" error when clicking on warnings/errors in the Messages window, it seems when the "jumping" is broken, the line numbers are wrong also.  I have attached a jpg showing line numbers in the 2nd to left column that clearly don't have anything to do with the actual line number as seen at the end of each message "line 46" vs. line 5443 ... hope that helps, the "(non) jumping" really needs to be fixed.

... assuming my memory is reliable :-)

Ta

[oBFusCATed]

Can you post a minimal sample code that fails?
Also can you reproduce this with the c++ compiler?

[DrOli]

Attached is a very simple project that fails (to jump) when I am using the GCC 5.3.0/ GDB 7.10.1 Toolchain.

In fact, after extensive testing, ALL but one of my CB Fortran projects fail to jump with 530/7101, but ALL of which WORK correctly with 492/79

I have only one C project in CB, and that works with both 492, and 530 etc.

I did find one Fortran project which works with 530.  It is a very large project, so have not included it.


Though it may be red-herring, it is possible that the information on this page (https://gcc.gnu.org/gcc-5/changes.html) might be a hint, particularly around the line

"Incomplete support for colorizing diagnostics emitted by gfortran has been added" in the Fortran Section of the page.


Cheers

DrO


P.S.  I have also included a (truncated) copy of the PDF I sent in with my  GDB Crash/Bug report (GDB Crash Bug v0i_x.pdf).  IT has a couple of sections that might be (after a little clean up)  of use to CB for general distribution in relation to instructions on debugging DLL/Excel projects, and how to set-up CB for those cases.  I understand you may be too busy, and might prefer to "switch to ignore" ... but if any of looks useful, I can always clean up the CB relevant Sections a bit for general consumption.

[DrOli]

FYI, it looks like the newer version of GCC Toolchain (5.3.0-5) with GDB 7.11.1 via MSys2 (cf. my earlier 5.3.0/7.10.1 directly from MinGW-64) has corrected the "breakpoint crash", and it seems to be working correctly now (have also updated my GDB bug report) ... whoo hoo :-)

FYI, CB has some difficulty recognising the ToolChain under the MSys2 MinGW setup.  CB keep insisting on reverting all the choices back to the old MinGW compiler/debugger links ... got there in the end with "persistence/repetition", but thought you should know.

The CB "non-jumping" thing is still an issue.  It would be great to have that working.



BTW, is CB built on GTK3 in any way?

[BlueHazzard]

FYI, it looks like the newer version of GCC Toolchain (5.3.0-5) with GDB 7.11.1 via MSys2 (cf. my earlier 5.3.0/7.10.1 directly from MinGW-64) has corrected the "breakpoint crash", and it seems to be working correctly now (have also updated my GDB bug report) ... whoo hoo :-)

Told you it is a gdb/gcc and not a codeblocks bug/incompatibility

FYI, CB has some difficulty recognising the ToolChain under the MSys2 MinGW setup.  CB keep insisting on reverting all the choices back to the old MinGW compiler/debugger links ... got there in the end with "persistence/repetition", but thought you should know.

What is the default installation directory for Msys2 and are you using it, or do you use some own path?

BTW, is CB built on GTK3 in any way?

C::B uses wxWidgtes and wxWidgets uses the native window system. So under windows the MFC and under Linux GTK....  http://www.wxwidgets.org/about/

greetings

[DrOli]

Cheers for that.

Any news on the "(not) jumping" issue?