1 Topic by JohnWasilewski (edited by JohnWasilewski 2014-11-06 14:00:49)

Topic: SIGSEGV - segmentation fault, only when debugging

My problems tend to be very strange ones, and I have another that again fits this description.

I have a large project, which compiles, links and runs perfectly well, without runtime error and with correct output results.
The executable runs without error, right through to completion.

There is some functionality I'd like to improve, however, which I can't seem to make work.
This, however, is NOT the problem.

The problem is that, whenever I try to use the debugger on the fully-working program, just in order to follow the program execution through and try to see what I need to modify in order to improve its functionality, the debugger crashes the unmodified version of my seemingly-correct program.  As a result, I am unable to use the debugger as a software development tool.

The crash emits this error message:
   Debugger Error
   Signal received SIGSEGV - Segmentation fault


I have discovered that the program runs without a debugger error if I insert a breakpoint immediately before a particular DISLIN call.  It is the DISLIN instruction,

    CALL DWGfil('Structure DATA filename',F%Path,'*.*').

This instruction causes - or should cause - DISLIN to display a file-selection dialog box and to return the pathname of the file selected by the program user.  There appears to be nothing wrong with either DISLIN or the way I have used it because, as I say, when I run my program without using the debugger, it works without crashing and without any ereror of any kind.  It makes no difference whether I run it from withing Simply Fortran or by executing the executable as a free-standing Windows program.  It works correctly in both cases.  I have also had Helmut Michels (DISLIN author) and a colleague of Helmut's, both very kindly check DISLIN's use of this routine, and they both say it has no error.

A further clue, though not one which has helped me find a solution, is that, when the debugger crashes with a SIGSEGV fault, it appears to do so part-way through executing DISLIN's call to its DWGfil routine.  That is to say, the crash occurs after drawing the entire dialog box and after just starting to populate it with the filenames list in the current directory.  It manages to write-into the dialog box just the first filename, then freezes on the SIGSEGV error.

An even further clue is that I have occasionally managed to paste fast enough into the dialog box the name of the file to open, before the crash occurs.  When I've managed this, the SIGSEGV crash does not occur straight away, but the program execution then gets a bit further, before finally crashing in the same way, with a SIGSEGV error.

Jeff, or anyone else, if you have any ideas, I'd greatly appreciate any help to get me through this.
I'm in the Catch-22 situation that I can't use the debugger to find the cause of teh problem because the program only crashes when I run it under the debugger.
---
John

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

I've managed to replicate your problem in certain circumstances, though not every time.  The problem seems to get worse when the path is "lengthy."   The length of the path does not, however, appear to have anything to do with your code.  Changing the path length to something large (8192 characters,  for example) in your code doesn't fix the problem at all.

One thing I do notice is that the file dialog does take a significant amount of time to appear.  This behavior, at least in my experience, tends to be due to improperly preparing the OPENFILENAME structure when accessing the Windows API.  Don't quote me on that, though.  My experience is somewhat anecdotal. 

I'm going to try a few more ideas with your code.  However, I don't actually see anything wrong yet.  It could be that the debugger is catching an actual problem.

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

My goodness how you fly at a problem Jeff ! 

There are at least 50 or 60 source files to compile and link, and that's before you start searching through tthe code to try to follow it, and then then start changing things in the static library, which necessitates re-compiling both the library and the application.  And it must be at least an hour ago that I sent you all the files!
--
J.

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

Still no luck on my end.  However, the DISLIN people might like to see the stacktrace from the calling thread:

#0  0x76052aae in KERNELBASE!CreateFileW ()
   from C:\WINDOWS\SysWOW64\KernelBase.dll
#1  0x760839f6 in KERNELBASE!GetVolumeInformationByHandleW ()
   from C:\WINDOWS\SysWOW64\KernelBase.dll
#2  0x05013a68 in ?? ()
#3  0x760842cc in KERNELBASE!GetVolumePathNameW ()
   from C:\WINDOWS\SysWOW64\KernelBase.dll
#4  0x760840bb in KERNELBASE!GetVolumePathNameW ()
   from C:\WINDOWS\SysWOW64\KernelBase.dll
#5  0x766c0fbd in SHGetNameFromIDList () from C:\WINDOWS\SysWOW64\shell32.dll
#6  0x766ff58d in SHELL32!CreateStorageItemFromShellItem_FullTrustCaller_ForPack
age_WithProcessHandle () from C:\WINDOWS\SysWOW64\shell32.dll
#7  0x76aa9410 in SHLimitInputEdit () from C:\WINDOWS\SysWOW64\shell32.dll
#8  0x67eb41b4 in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#9  0x67eac282 in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#10 0x67ea7e1d in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#11 0x67e9b41c in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#12 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#13 0x76427a9a in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#14 0x7642ce71 in USER32!CallWindowProcW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#15 0x71d93d76 in DefSubclassProc ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#16 0x71d93d57 in DefSubclassProc ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#17 0x67ea7c75 in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#18 0x71d9054a in DPA_GetPtr ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#19 0x71d93b26 in InitCommonControls ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#20 0x0000004e in ?? ()
#21 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#22 0x76427a9a in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#23 0x7642ce71 in USER32!CallWindowProcW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#24 0x67e4402b in FindStdColor () from C:\WINDOWS\SysWOW64\duser.dll
#25 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#26 0x76427a9a in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#27 0x76427bed in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#28 0x76427d81 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#29 0x77a9c692 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#30 0x0028be90 in ?? ()
#31 0x7642d400 in USER32!SendMessageW () from C:\WINDOWS\SysWOW64\user32.dll
#32 0x71d8b4fa in ImageList_Add ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#33 0x71dc219e in DPA_Merge ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#34 0x71dc2add in DPA_Merge ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#35 0x71dc3924 in DPA_Merge ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#36 0x71dc373b in DPA_Merge ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#37 0x71dca478 in DPA_EnumCallback ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#38 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#39 0x76427a9a in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#40 0x7642ce71 in USER32!CallWindowProcW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#41 0x71d93d76 in DefSubclassProc ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#42 0x71d93d57 in DefSubclassProc ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#43 0x67ea791c in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#44 0x67ea78b1 in EXPLORERFRAME!DllGetClassObject ()
   from C:\WINDOWS\SysWOW64\ExplorerFrame.dll
#45 0x71d9054a in DPA_GetPtr ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#46 0x71d93b26 in InitCommonControls ()
   from C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df
_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
#47 0x0000000f in ?? ()
#48 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#49 0x7642930f in USER32!GetWindowThreadProcessId ()
   from C:\WINDOWS\SysWOW64\user32.dll
#50 0x76427bed in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#51 0x76427d81 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#52 0x77a9c692 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#53 0x0028c9bc in ?? ()
#54 0x67d3b630 in DUI70!?Paint@HWNDHost@DirectUI@@UAEXPAUHDC__@@PBUtagRECT@@1PAU
4@2@Z () from C:\WINDOWS\SysWOW64\dui70.dll
#55 0x67d0f830 in DUI70!?GetPadding@Element@DirectUI@@QAEPBUtagRECT@@PAPAVValue@
2@@Z () from C:\WINDOWS\SysWOW64\dui70.dll
#56 0x67e13444 in ?? () from C:\WINDOWS\SysWOW64\duser.dll
#57 0x67e15cad in InvalidateGadget () from C:\WINDOWS\SysWOW64\duser.dll
#58 0x67e15cd4 in InvalidateGadget () from C:\WINDOWS\SysWOW64\duser.dll
#59 0x67e15cd4 in InvalidateGadget () from C:\WINDOWS\SysWOW64\duser.dll
#60 0x67e15cd4 in InvalidateGadget () from C:\WINDOWS\SysWOW64\duser.dll
#61 0x67e15afd in InvalidateGadget () from C:\WINDOWS\SysWOW64\duser.dll
#62 0x67e15699 in LookupGadgetTicket () from C:\WINDOWS\SysWOW64\duser.dll
#63 0x67e15de5 in InvalidateGadget () from C:\WINDOWS\SysWOW64\duser.dll
#64 0x67e14ae1 in GetGadgetFlags () from C:\WINDOWS\SysWOW64\duser.dll
#65 0x67e14707 in GetGadgetFlags () from C:\WINDOWS\SysWOW64\duser.dll
#66 0x67e12efe in ?? () from C:\WINDOWS\SysWOW64\duser.dll
#67 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#68 0x7642930f in USER32!GetWindowThreadProcessId ()
   from C:\WINDOWS\SysWOW64\user32.dll
#69 0x76427bed in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#70 0x76427d81 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#71 0x77a9c692 in ntdll!KiUserCallbackDispatcher ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#72 0x0028d940 in ?? ()
#73 0x76442626 in USER32!IsDialogMessageW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#74 0x764426a8 in USER32!IsDialogMessageW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#75 0x76442f93 in USER32!IsDlgButtonChecked ()
   from C:\WINDOWS\SysWOW64\user32.dll
#76 0x76443036 in USER32!DialogBoxIndirectParamAorW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#77 0x76442ffb in USER32!DialogBoxIndirectParamW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#78 0x76193af4 in GetFileTitleW () from C:\WINDOWS\SysWOW64\comdlg32.dll
#79 0x761af6a0 in GetSaveFileNameW () from C:\WINDOWS\SysWOW64\comdlg32.dll
#80 0x761af5f4 in GetSaveFileNameW () from C:\WINDOWS\SysWOW64\comdlg32.dll
#81 0x761af54c in GetSaveFileNameW () from C:\WINDOWS\SysWOW64\comdlg32.dll
#82 0x761af441 in GetSaveFileNameW () from C:\WINDOWS\SysWOW64\comdlg32.dll
#83 0x761c93ea in GetOpenFileNameW () from C:\WINDOWS\SysWOW64\comdlg32.dll
#84 0x0048c25e in Get_OpenFile ()
#85 0x00491c82 in dwgfil ()
#86 0x0048493d in dwgfil_ ()
#87 0x00424518 in getfilename (changepath=.TRUE.)
    at .\Source\FileHandler.for:527
#88 0x00429136 in fopen () at .\Source\FileHandler.for:167
#89 0x004856ad in qqdcbexe ()
#90 0x0048e68a in DisWidget@16 ()
#91 0x76427834 in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#92 0x76427a9a in USER32!CallNextHookEx () from C:\WINDOWS\SysWOW64\user32.dll
#93 0x7642988e in USER32!GetMessageW () from C:\WINDOWS\SysWOW64\user32.dll
#94 0x764298f1 in USER32!DispatchMessageW ()
   from C:\WINDOWS\SysWOW64\user32.dll
#95 0x00490a1b in wgfin ()
#96 0x0048394c in winmenus () at .\Source\WinMenus.for:487
#97 0x0042f049 in instruct () at .\Source\INSTRUCT.for:408
#98 0x0042f098 in main (argc=1, argv=0x6e1010) at .\Source\INSTRUCT.for:361
#99 0x00401412 in __tmainCRTStartup ()
#100 0x75dc919f in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SysWOW64\kernel32.dll
#101 0x77ab0bbb in ntdll!RtlInitializeExceptionChain ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#102 0x77ab0b91 in ntdll!RtlInitializeExceptionChain ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#103 0x00000000 in ?? ()

The above might help them some more.  I think the problem is internal to DISLIN.  I can't think of anything else to test without more information concerning DISLIN's internals, and I'd rather not know anything about it for licensing reasons.

I find it odd that they're calling "GetSaveFileName" to generate a file dialog.

I might be able to build a simple routine that can create a Windows-standard file dialog from Windows rather than relying on DISLIN for that purpose.  It should be rather easy.

Jeff Armstrong
Approximatrix, LLC

5 Reply by JohnWasilewski (edited by JohnWasilewski 2014-11-06 19:38:01)

Re: SIGSEGV - segmentation fault, only when debugging

I've just posted this on the Google Groups "DISLIN USERS" forum, at
https://groups.google.com/forum/#!topic … QqfYEb8nZA :


Dear Helmut, Armin, 'DH' and others,

I have still not solved this problem but I have new information which seems quite strongly to suggests a problem with either GDB, GFortran or just possibly DISLIN.

I have noticed in all my investigations that I can get my large project to run successfully, error-free, and that it is only when debugging that I am encountering a SIGSEGV error.  I have therefore extended your test program Helmut, as shown below, then I've re-tested it with and without the debugger:

      program t1
      USE Dislin
      CHARACTER*255 FiName
      FiName=' '

      CALL DWGfil('Structure DATA filename',FiName,'*.*')

      Print*, "You selected this file: ["//TRIM(FiName)//"]"
      end program t1

When I compile this with GFortran and then run this as an executable, it works without error. 
When I try to run it in the GDB debugger, it crashes with the SIGSEGV error.

Can anyone replicate this behaviour, and if anyone can, can anyone work out where the problem lies?
---
Yours sincerely,
John

Re: SIGSEGV - segmentation fault, only when debugging

Jeff, I'll also post something on the DISLIN-USERS forum to include the information you have provided,
Thank you very much for it,
---
John

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

That's especially interesting (and encouraging) that the simplified version does crash as well.  I think that might help show that something is fishy in DISLIN's DWGfil routine.

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

Jeff, unless I am imagining it, did you not change the SF debugger to GDB from a different debugger you used to include in SF version 1?  I don't recall the name of the previous debugger but I seem to recall that there was a different one in your earlier versions of SF.

If that is correct, could you try compiling Helmut's very short test program with SF2.7, then debugging the executable with the other debugger?
---
J.

Re: SIGSEGV - segmentation fault, only when debugging

A further post just in on the DISLIN forum:

Hi John,

I have tried the simple test program on my OpenSuSE 12.2 linux system with

GNU Fortran (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773]
GNU gdb (GDB) SUSE (7.5.1-2.5.1)
and the DISLIN package "dislin-10.4-1.x86_64"

I can compile it from the command-line:
gfortran -odistest distest.f -I /usr/local/dislin/gf -ldislin
and it runs fine.

If i compile it for debugging mode with:
gfortran -odistest -g distest.f -I /usr/local/dislin/gf -ldislin
it runs fine both when I start it from the command-line (without debugger) and when running it within the gdb debugger.

But according to your Debugger output, the error is triggered very deep inside the Windows function calls so it may be a specific problem under Windows.


Cheers,
Armin

Re: SIGSEGV - segmentation fault, only when debugging

Jeff, Helmut Michels (DISLIN author) has posted this on the DISLIN forum:


Helmut Michels    
9:46 AM (16 minutes ago)

Hi John,

I have also tried the short example with two gfortran and gdb versions on Windows 7 64-bit. No crash.

gfortran 4.4.0  32-bit,  GNU gdb 6.8  32-bit

gfortran -g -Ic:\dislin\gf   john.for   \dislin\disgf.a   -luser32 -lgdi32 -lopengl32
gdb a.exe
run
....
program exited normally.

gfortran 4.5.2  64-bit,  GNU gdb 7.1  64-bit

gfortran -g -Ic:\dislin64\gf \dislin64\dismg.a  -luser32  -lgdi32  -lopengl32
gdb a.exe
run
...
program exited normally.

Which gfortran and gdb versions are you using?

Best regards,

Helmut

Please can you advise me on the version numbers he asks for?
---
John

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

Simply Fortran 2.17 uses GNU Fortran 4.9.1 and GNU GDB 7.8.  I was seeing the crashes with 32-bit builds.

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

The version number in the current SFPM files for DISLIN might also be helpful Jeff, please?
---
J.

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

SFPM does not actually provide DISLIN.  Rather, it starts a download process from the DISLIN website itself.  It actually depends on when you installed the DISLIN package through the package manager and the version available at the time.  Our distributing DISLIN directly would most likely violate DISLIN's complicated licensing.

I would guess you are using 10.4.2 (July 2014) or 10.4.3 (September 2014).

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

On Thursday, November 6, 2014 3:43:12 PM UTC, Helmut Michels wrote [on the DISLIN forum]

John,

you are using a very new version of gcc/gfortran. The newest version that I could find at www.mingw.org and tdm-gcc.tdragon.net was 4.8.1. So, I downloaded and installed gcc 4.9.1 32-bit from www.equation.com. But again, the dwgfil example code was running fine within the debugger.

Best regards,

Helmut

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

I'm not sure what the problem is in that case.  "Very new version" is a bit unfair.  4.9.1 was released in July as a minor point release, (4.9 was released in April), and it isn't even the current version.   

I'm going to quickly write a Fortran-callable module for selecting a filename using the Windows file selection dialog.  I'm not sure why it isn't working in DISLIN.

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

On hearing from Helmut that it works fine for him, when he uses the same versions of GFortran and GDB as we use, I've been trying this program over and over with different SF options. to try to find some compiler or linker setting that causes it to work without SIGSEGV error when running it in the debugger:

      program t1
      USE Dislin
      CHARACTER*255 FiName
      FiName=' '
      CALL DWGfil('Structure DATA filename',FiName,'*.*')
      Print*, "You selected this file: ["//TRIM(FiName)//"]"
      end program t1

No luck so far but I'll keep trying.  I! anyone has any ideas, love to hear them"
---
John

Re: SIGSEGV - segmentation fault, only when debugging

Silly question I'm sure but the problem couldn't possibly be with the linker, could it?

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

If we were using different compilers, then we were doubtless using different linkers, which are part of the "binutils" package.  I'm not sure what version we're shipping at the moment.  However, I doubt that would cause the issue.

Jeff Armstrong
Approximatrix, LLC
  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

If you're interested in trying, I've built a small library that provides a file open and save dialog from Fortran that doesn't seem to crash.  It is not an exact replica of DISLIN's functions, but it is similar enough:

http://packages.simplyfortran.com/package/72.html

There is no example project included, but the documentation can be viewed at:

https://bitbucket.org/ArmstrongJ/wfdialogs/overview

and an example program can be seen at:

https://bitbucket.org/ArmstrongJ/wfdial … ?at=master

When linking, you'll need to remember to add the flags:

-lwfdialogs -lcomdlg32

Hopefully you can just use these calls rather than the problematic DISLIN call.

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

I Like this new library very much, Jeff.
Might you be adding to it gradually?

I'd appreciate also a 64bit version.

I like the way that, as well as accepting a filename extension filter, the the filename requester dialog also accepts a string for naming or describing the default file type.

Small suggestion:
The filename requester dialog box could benefit from a text string parameter that can be passed to it, to display in the top bar.  I was using this in the DISLIN version to display a prompt.
---
John

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

I've added the file dialog title argument like you suggested.  Also, it now allows requesting text entry or selection from a list via simple calls.  The latest version is available in the Package Manager.

It already supports 64-bit projects.  Just switch your project to 64-bit and compile.  It should work fine.

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

Thanks Jeff. 
Works perfectly.

I see the Package Manager mentions that is 32/64.  I should have noticed that.
This is an extremely helpful development for SF.
I do hope you can continue to add to this library. 
I think you should also mention it in SF "news".
---
J.

Re: SIGSEGV - segmentation fault, only when debugging

SitRep:

I am still getting this SIGSEGV fault on a project whenever I use the debugger, on a program which compiles, links, loads and runs without error when not debugging.  This is after switching away from DISLIN for filename requester dialogs and using Jeff's very neat routines instead.

If anyone else has the same experience, it might be helpful to hear about it.

  • jeff
  • Administrator
  • Offline

Re: SIGSEGV - segmentation fault, only when debugging

John,

At what point does the program crash now?  Is it when the file dialog is opened?

Jeff Armstrong
Approximatrix, LLC

Re: SIGSEGV - segmentation fault, only when debugging

It crashes to a SIGSEGV fault when trying to execute the statement at label 10 in the code fragment below:

      SUBROUTINE GetFileName(ChangePath)
C     ----------------------------------
C     jw / 25-07-12  1st draft started
C     jw / 15-02-14  last rev.

C     On returning from this subroutine:

C The INPUT file pathname should be stored in
C TRIM(F%Path)//TRIM(F%Name)//'.'//TRIM(F%I%Ext).

C     F%I%Exists should indicate whether 
C     the INPUT file already exists.
C     F%I%OPEN should indicate whether 
C     it is already open.

C     F%bakExists should indicate whether
C     a BAK file already exists.
C     (It should not be open).

C     F%O%Exists should indicate whether 
C    the OUTPUT file already exists.
C     F%O%OPEN should indicate whether 
C     it is already open.

      USE Dislin
      USE Files
      USE wfdialogs
      LOGICAL EXISTS, ChangePath

C     IF(F%Named) RETURN

C     Input filename not yet known
      F%Path = ('      ')
      F%Name = (' ')
      F%I%Exists = .FALSE.
      F%I%OPEN = .FALSE.
      F%BAKexists = .FALSE.
      F%BAKdeletable = .FALSE.

      CALL SWGOPT('STANDARD','DIALOG') !Use STANDARD file dialog boxes
C     Prompt user for a data input Path\filename.ext
      F%Path = ' '

10    IF(RequestOpenFile(F%Path,
     +'Default DATA file type','*.ins',
     + 'Enter or select a structure DATA filename')) THEN
          CALL SWGOPT('TOP','DIALOG')!Keep all other dialog boxes on top

          CALL ParsePath(F%PATH,F%Name,F%I%Ext)
          IF(LEN_TRIM(F%I%Ext).EQ.0) F%I%Ext='ins'
          F%O%Ext = 'rtf'
          F%Named = .TRUE.

C         Set the current directory to that of the chosen file
          IF(ChangePath) CALL CHDIR(F%Path,iDone)
          :
          :
          : {more}
          :
          :
          :

The crash happens mid-way through the process of drawing and populating the filename requester dialog box.  At first, it managed only to draw the box outline and insert the title-bar caption, 'Enter or select a structure DATA filename', but the box was empty.  When I commented out the next line, viz,

          CALL SWGOPT('TOP','DIALOG')!Keep all other dialog boxes on top

this enabled the dialog box to start to fill, with about 30% of its normal content being written into it before the crash.

The crash does not happen when running outside the debugger.

If you have time to look into this any further and would like the latest version of my project code, please let me know and I'll send it.
---
John