Author Topic: SIGFPE crash when debug Excel dll  (Read 8111 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: SIGFPE crash when debug Excel dll
« Reply #15 on: March 19, 2016, 11:17:57 pm »
No idea what is ArrayVisualizer.
To view custom types you need to write python printers for gdb. For more info inspect gdb's documentation.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #16 on: March 23, 2016, 04:05:10 pm »
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.
« Last Edit: March 23, 2016, 04:08:33 pm by DrOli »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: SIGFPE crash when debug Excel dll
« Reply #17 on: March 23, 2016, 08:34:09 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).

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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #18 on: March 28, 2016, 02:52:45 pm »
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 :-)



Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: SIGFPE crash when debug Excel dll
« Reply #19 on: March 29, 2016, 12:24:29 am »
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...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #20 on: March 30, 2016, 09:52:23 pm »
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

Offline tigerbeard

  • Multiple posting newcomer
  • *
  • Posts: 114
Re: SIGFPE crash when debug Excel dll
« Reply #21 on: March 30, 2016, 10:26:40 pm »
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... 8)

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #22 on: March 31, 2016, 10:09:26 pm »
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

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: SIGFPE crash when debug Excel dll
« Reply #23 on: March 31, 2016, 10:24:06 pm »
Can you post a minimal sample code that fails?
Also can you reproduce this with the c++ compiler?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #24 on: April 01, 2016, 01:49:35 am »
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.
« Last Edit: April 01, 2016, 01:51:52 am by DrOli »

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #25 on: April 08, 2016, 03:07:19 am »
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?

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2987
Re: SIGFPE crash when debug Excel dll
« Reply #26 on: April 10, 2016, 08:36:02 pm »
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

Offline DrOli

  • Multiple posting newcomer
  • *
  • Posts: 40
Re: SIGFPE crash when debug Excel dll
« Reply #27 on: April 15, 2016, 04:42:43 pm »
Cheers for that.

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