Topic: SF 2.39 Indexing Problem

Hi Jeff,

I'm experiencing unusual problems with the new SF 2.39 interface. When a project is loaded (30 files), SF continues to index with the display: Syntax: Disabled Indexing: 2 Files - Working...

The editor then slows down to a snails pace and other issues arise. Program lines cannot be commented or uncommented. The search function doesn't work. The edited files cannot be saved.  The build option does not save the file.

Am I the only person experiencing this unusual behavior with SF 2.39?

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

Frank,

That doesn't sound like an "Indexing Problem," but, rather, just a major, general bug.  Would you be open to emailing your project and source files to me?  I obviously am not experiencing these issues on my end.

EDIT: Also, did you try version 2.38?  I'm not sure enough changed between versions to cause these issues.

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

Jeff,

I'm using Windows 7 (64 bit) and I don't think the SF interface environment problems I'm experiencing are program specific.  I tried repairing SF, and removing it all together and reinstalling SF 2.39 to no avail.  Thus far the problem occurs with a large (45 file project) and a small 3 file project.  As best as I can determine the issue only arises after a 'build', then I cannot save edits nor can I do any search functionality in SF.  The file window in SF just freezes until I 'x' remove it and redisplay it from the project menu again.

I don't recall this happening with SF 2.38, but I'm not sure which version I upgraded from 2.37 or 2.38.  I'll try removing SF 2.39 and loading version 2.38 and let you know if the problem persists.

Frank

Re: SF 2.39 Indexing Problem

Jeff,

Actually I never installed SF 2.38, so I upgraded from 2.37 to 2.39.

Frank

Re: SF 2.39 Indexing Problem

Jeff,

I tried installing SF 2.37 on top of version 2.39 without uninstalling 2.39, and it appears to being working just fine now.

Would you like me to now install 2.39 on top of 2.37 and see if the problem reoccurs?

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

Frank,

I still can't replicate the issue on my end. 

I'm surprised Windows allowed you to install "SF 2.37 on top of version 2.39" because the 2.37 installer should fail if a newer version is detected.  Installing "2.39 on top of 2.37" will actually just uninstall version 2.37 before installing 2.39.  Simply Fortran's installer does not re-use components from previous installations other than user-defined settings.

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

Jeff,

Further remedial actions completed -
1. I removed SF 2.37 by running the SF 2.39 installer and selecting the 'remove' SF option.
2. I then rebooted the system and let it update.
3. I re-installed SF 2.39 and loaded a small project.
4. The SF interface problems reappeared, but only after BOTH a build and then when the 'build' window at the bottom part of the screen is deleted by selecting the 'x' to removed the window.

If the 'build' window is not deleted, the program editing features function normally (commenting/uncommenting, searching, and scrolling).  But if after a build the 'build' window is deleted ('X'), then the program editor freezes.

My understanding is that the term 'bug' was coined by IBM when they found that a vacuum tube in one of their computers was short circuited by a bug.  I wish this 'bug' was as easy to identify.

Frank

Re: SF 2.39 Indexing Problem

Jeff,

How can I download SF 2.38 so I can compare it to 2.39?
SF 2.38 is no longer listed in the SF archive downloads.

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

Frank,

I've sent you an email, but, for now, there's no need to try 2.38.  It will behave the same as 2.39.

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

drfrank wrote:

. . ..the term 'bug' was coined by IBM when they found that a vacuum tube in one of their computers was short circuited by a bug... . .  .
Frank

That's as I also recall reading about.  Figuratively, of course, but IBM used the  word to mean a fault, or an error, in the code, and three cheers for IBM, as well as you, Jeff, for calling a spade a spade (as it were).  Clarity lives on, albeit only in isolated pockets nowadays, of technology and commerce!

I don't want to lose my pension so I'll not name the company which I believe first taught the world how to dissemble by putting perfectly good English words through the mangle and using them to avoid calling a spade a spade. 

When a machine, or a computer program, or a door handle doesn't work,
  - IT HAS: a fault. 
  - I DO NOT HAVE: "issues"!

When a well-known wordprocessor still sometimes wrecks the format of an entire document bar the current paragraph, if one uses 'copy format' to arrange that paragraph similarly to another, this is not an "issue".  It is a  B  U  G for Pete's sake!

Sorry about the off-topic rant, but I'm done.
And the art of the mixed metaphor lives on!

Re: SF 2.39 Indexing Problem

Jeff,

The issue is related to the use and then removal 'X' of the horizontal open build panel at the lower part of the SF screen.  The problem does not arise when using vertical build panels selected in the 'Options/Tabs' menu.

One additional question is related to indexing, which causes SF screen to continue to refresh very slowly when the project is VERY large.  Is there an option to turn-off the indexing?

Even when shown to be 'Syntax Disabled', the indexing continues working every time the cursor is moved in the program.
For example, Syntax: "Disabled Indexing: 2 Files - Working..."

I've also had build crashes of SF 2.39 that I've not experienced with earlier versions.

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

A build will be out next week fixing the closing of tabs and Simply Fortran's confusion about the new current tab.

Indexing cannot be disabled.  In fact, I might remove the status mention of it since most users seem to think its unnecessary.  How big is a "VERY large" project?  Simply Fortran is regularly tested against projects with 100s of files, and it seems responsive on my end. Just trying to understand the issue.

What do you mean exactly by "build crashes?"

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

Jeff,

Thank you provide a panel build window fix.  I look forward to trying it.

Regarding, the size of the the program where I'm experience crashes, it's not huge, just about 45 files producing a executable of around 3000k.  By build crashes I mean that SF just aborts completely on occasion when building.  I do recall an earlier message that said something like 'Dependency timeout' or something like that.

Today I received a Make Construction Error, "A severe, internal error occurred while creating the Makefile. Please report this issue (SEH) to support@approximatrix.com".  But the SF panel displayed "*Complete* Generating Makefile... Okay".

In SF under code generation menu I've set the Optimization to "Common" but checked the [x] Agressive Loop Optimization.

Also under Compiler Flags/Fortran Compiler I inserted the following:
-O2 -ffrontend-optimize -Wl,-stack_size,0xFFFFFFFF,-stack_addr,0xC0000000,--heap=0x00100000

Might this be causing the problem?

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

Dependency timeouts mean, when building, that Simply Fortran has not completed dependency scanning for the project.  It should just require more time.  The compiler is never launched in this case because the makefile was never completely created.,= An SEH error is drastically more severe.  If you do see one occur, you cab email whatever makefile is present after the error (it probably won't be complete) so I can troubleshoot the problem.

The compiler options would not cause any of the issues you've described.

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

Jeff,

I'd like to follow up on the fwin.exe stopped working  crashes.  Several times using SF 2.39 I've experienced SF crash completely (exe aborts with a "fwin.exe stopped working" error). At times it occurs during a build and other times just while I'm editing a program file.

Although there's always a possibility that it's due to the program I'm working on, especially during a build error.  But I've not experienced previous versions of SF crashing and totally shutting down while editing a program file.

Any thoughts?

Frank

Re: SF 2.39 Indexing Problem

Jeff,

Here's an example of the Make file where a SF 2.39 crash occurred during a program build.

#
# Automagically generated by Approximatrix Simply Fortran 2.39
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f

IDIR=-IC:/Users/Julianna/AppData/Local/sfpm/64/include

LDIR=-LC:/Users/Julianna/AppData/Local/sfpm/64/lib


OPTFLAGS= -O2

SPECIALFLAGS=$(IDIR)

RCFLAGS=-O coff

PRJ_FFLAGS=-O2 -ffrontend-optimize -Wl,-stack_size,0xFFFFFFFF,-stack_addr,0xC0000000,--heap=0x00100000

PRJ_CFLAGS=

# Auto-including AppGraphics libraries.
PRJ_LFLAGS=-lappgraphics -lgdi32 -lcomdlg32 -lcomctl32 -luuid -loleaut32 -lole32 -mcmodel=medium

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\EZCalc_Global.o": ".\EZCalc_Global.F90" "modules\nrtype.mod"
    @echo Compiling .\EZCalc_Global.F90
    @$(FC) -c -o "build\EZCalc_Global.o" $(FFLAGS) ".\EZCalc_Global.F90"
.
.
.
    @echo Deleting build\SHARC8.51_ScrollMenu_Module.o and related files
    @$(RM) "build\SHARC8.51_ScrollMenu_Module.o" "modules\mainmenu.mod"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting Ezy-CurvFit4.exe
    @$(RM) "Ezy-CurvFit4.exe"

"Ezy-CurvFit4.exe":  "build\EZCalc_Global.o" "build\EZCALC_Main2.o" "build\EZCalc_Module.o" "build\My_Function_Module.o" "build\SHARC8.50_AxisScale.o" "build\SHARC8.50_BIOS_Module.o" "build\SHARC8.50_CGM8_Module.o" "build\SHARC8.50_CheckData.o" "build\SHARC8.50_CheckParser_MDL.o" "build\SHARC8.50_EigenPCA_Mod.o" "build\SHARC8.50_Error_Handler.o" "build\SHARC8.50_Func_UDF_MDL.o" "build\SHARC8.50_FunctParser.o" "build\SHARC8.50_Globals.o" "build\SHARC8.50_LaunchExe.o" "build\SHARC8.50_LaunchExeWrapper.o" "build\SHARC8.50_LaunchPath.o" "build\SHARC8.50_LevelButtons.o" "build\SHARC8.50_MachPrecision.o" "build\SHARC8.50_Main_Sub_MDL.o" "build\SHARC8.50_Main_UDF.o" "build\SHARC8.50_MARQ21_Module.o" "build\SHARC8.50_Matrix_Inverse .o" "build\SHARC8.50_nrUtil.o" "build\SHARC8.50_Operators.o" "build\SHARC8.50_PercentProgressBar.o" "build\SHARC8.50_Plot.o" "build\SHARC8.50_PlotXYWindow2.o" "build\SHARC8.50_Pvalue.o" "build\SHARC8.50_ReadWrite.o" "build\SHARC8.50_Reinsch_Smooth_Module.o" "build\SHARC8.50_ResidualsWindow.o" "build\SHARC8.50_ResultsWindow.o" "build\SHARC8.50_RKF7n_Module.o" "build\SHARC8.50_ROBUSTWT_Module.o" "build\SHARC8.50_Scosine.o" "build\SHARC8.50_SemiLogWindow2.o" "build\SHARC8.50_StiffDiff3a.o" "build\SHARC8.50_StrLib.o" "build\SHARC8.50_TAU2_Outliers.o" "build\SHARC8.50_TextBox_Module.o" "build\SHARC8.50_XYDataWindow.o" "build\SHARC8.51_ScrollMenu_Module.o" "build\sf_default_resource.res" "build\EzyCurvFit900.prj.target"
    @echo Generating Ezy-CurvFit4.exe
    @$(FC) -o "Ezy-CurvFit4.exe" -static "build\EZCalc_Global.o" "build\EZCALC_Main2.o" "build\EZCalc_Module.o" "build\My_Function_Module.o" "build\SHARC8.50_AxisScale.o" "build\SHARC8.50_BIOS_Module.o" "build\SHARC8.50_CGM8_Module.o" "build\SHARC8.50_CheckData.o" "build\SHARC8.50_CheckParser_MDL.o" "build\SHARC8.50_EigenPCA_Mod.o" "build\SHARC8.50_Error_Handler.o" "build\SHARC8.50_Func_UDF_MDL.o" "build\SHARC8.50_FunctParser.o" "build\SHARC8.50_Globals.o" "build\SHARC8.50_LaunchExe.o" "build\SHARC8.50_LaunchExeWrapper.o" "build\SHARC8.50_LaunchPath.o" "build\SHARC8.50_LevelButtons.o" "build\SHARC8.50_MachPrecision.o" "build\SHARC8.50_Main_Sub_MDL.o" "build\SHARC8.50_Main_UDF.o" "build\SHARC8.50_MARQ21_Module.o" "build\SHARC8.50_Matrix_Inverse .o" "build\SHARC8.50_nrUtil.o" "build\SHARC8.50_Operators.o" "build\SHARC8.50_PercentProgressBar.o" "build\SHARC8.50_Plot.o" "build\SHARC8.50_PlotXYWindow2.o" "build\SHARC8.50_Pvalue.o" "build\SHARC8.50_ReadWrite.o" "build\SHARC8.50_Reinsch_Smooth_Module.o" "build\SHARC8.50_ResidualsWindow.o" "build\SHARC8.50_ResultsWindow.o" "build\SHARC8.50_RKF7n_Module.o" "build\SHARC8.50_ROBUSTWT_Module.o" "build\SHARC8.50_Scosine.o" "build\SHARC8.50_SemiLogWindow2.o" "build\SHARC8.50_StiffDiff3a.o" "build\SHARC8.50_StrLib.o" "build\SHARC8.50_TAU2_Outliers.o" "build\SHARC8.50_TextBox_Module.o" "build\SHARC8.50_XYDataWindow.o" "build\SHARC8.51_ScrollMenu_Module.o" "build\sf_default_resource.res" $(LDIR) $(PRJ_LFLAGS)

all: "Ezy-CurvFit4.exe" .SYMBOLIC
---------------SF crashed here-----------------------------------------

When I re-loaded SF 2.39 and tried to re-build the same program, I received the following...

==============================================================================
Generating Makefile... Okay
==============================================================================
Processing default resource
Generating Ezy-CurvFit4.exe

* Complete *
==============================================================================
Generating Makefile... Okay
==============================================================================
Processing default resource
Generating Ezy-CurvFit4.exe
c:/program files (x86)/simply fortran 2/mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: reopening Ezy-CurvFit4.exe: Permission denied

c:/program files (x86)/simply fortran 2/mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Permission denied
collect2.exe: error: ld returned 1 exit status
Error: Last command making (Ezy-CurvFit4.exe) returned a bad status
Error: Make execution terminated

* Failed *

I hope this is helpful,

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

drfrank wrote:

I'd like to follow up on the fwin.exe stopped working  crashes.  Several times using SF 2.39 I've experienced SF crash completely (exe aborts with a "fwin.exe stopped working" error). At times it occurs during a build and other times just while I'm editing a program file.

I think we do need to clear some terminology up.  If fwin.exe stops working, it constitutes a "crash" as you've described.  Version 2.38 and 2.39 might be using a new version of an internal database, which could be a culprit.  I'll look into that, although I haven't experienced similar crashes.  The multithreaded file scanner was introduced in 2.38, but, again, I haven't been able to reproduce crashing of the main development environment.

The "build error" that's problematic that you described earlier is the "SEH" error, which implies that the development environment's memory was corrupted at some point while creating a makefile.  Again, I'm not sure why that would occur nor can I reproduce it, but I suspect that the internal database is the cause.

The "Timeout" error can be caused by the dependency scanner, part of the indexing operation.  There is a timing issue in version 2.39 and all earlier versions that can cause builds to "Timeout" (which isn't a "crash," but, rather, a valid message) if file indexing operations haven't been complete.  It should already be fixed in the development version.

drfrank wrote:

Here's an example of the Make file where a SF 2.39 crash occurred during a program build.

So the makefile appears to be successfully created.  I don't see anything wrong.  If fwin.exe "crashed" here, it is simply due to an internal bug caused by, most likely, the internal database.  It would have been interesting if an "SEH" error were displayed.  Otherwise, everything appeared to work prior to a crash.

drfrank wrote:

When I re-loaded SF 2.39 and tried to re-build the same program, I received the following...

The output in the Build Status tab looks completely normal here.  You are seeing "Permission Denied" errors during linking, which means either your program did not properly terminate prior to building (check the Task Manager) or a virus scanner is not releasing a handle to the executable to allow the linker to overwrite the original executable.  That issue is entirely unrelated to everything else you've described.  Are you running a virus scanner, and, if so, which?

You have to remember that you're using a program to generate and later replace executables (I'm pretty sure our linker is set up to first delete then create a new executable, but I need to confirm...), an action which almost every virus scanner considers highly suspect.  A normal user wouldn't have any need to replace an executable, let alone create and then launch one.  Many popular, third-party scanners take a very dim view of compilers.  I don't have these type of issues with Microsoft's own scanner, however.

I will look into the internal database further next week.  I would guess that recent crashes would be due to that issue.

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

Jeff,

Thank you for your detailed response.  You are correct, after the so-called crash and truncated re-Build,  when Build was executed once again, it compiled perfectly.

Regarding the Virus scanner, I do use Microsoft Security Essentials and for computer maintenance real-time scanning with IOLO System Mechanic.

Thanks for looking into this issue and I look forward to the next version of SF.

Frank

Re: SF 2.39 Indexing Problem

Jeff,

You wrote: "An SEH error is drastically more severe.  If you do see one occur, you cab email whatever makefile is present after the error (it probably won't be complete) so I can troubleshoot the problem."

I inadvertently caused a syntax error programmatically, but upon a Build an (SEH) error occurred.
I've reconstruction the message here:

      END IF
           1
Error: Expecting END SUBROUTINE statement at (1)
Error: Last command making (build=SHARC8.50_CGM8_Module.o) returned a bad status
Error: Make execution terminated

* Failed *
==============
Generation Makefile... Okay

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Make Construction Error

! A sever, internal error occurred while creating the Makefile.
  Please report this issue (SEH) to support@approximatrix.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Make file resulting from the error is shown below:
--------------------------------------------------------------------------------
#
# Automagically generated by Approximatrix Simply Fortran 2.39
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f
IDIR=-IC:/Users/Julianna/AppData/Local/sfpm/64/include
LDIR=-LC:/Users/Julianna/AppData/Local/sfpm/64/lib
OPTFLAGS= -O2
SPECIALFLAGS=$(IDIR)
RCFLAGS=-O coff
PRJ_FFLAGS=-O2 -ffrontend-optimize -Wl,-stack_size,0xFFFFFFFF,-stack_addr,0xC0000000,--heap=0x00100000
PRJ_CFLAGS=

# Auto-including AppGraphics libraries.
--------------------------------------------------------------------------------

Thanks for you continued effort in the development of SF; I couldn't do without it.
Great application!

Frank

Re: SF 2.39 Indexing Problem

Jeff,

I've experienced another error with fwin.exe.  The following is the error message related to an "APPCRASH" from module ntdll.dll.
I've not experienced any problems with Windows 7.0 or running any other applications.

Message: "SF fwin.exe has stopped working:

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    fwin.exe
  Application Version:    0.0.0.0
  Application Timestamp:    59a03b42
  Fault Module Name:    ntdll.dll
  Fault Module Version:    6.1.7601.18247
  Fault Module Timestamp:    521ea8e7
  Exception Code:    c0000005
  Exception Offset:    0002e3be
  OS Version:    6.1.7601.2.1.0.768.3
  Locale ID:    1033
  Additional Information 1:    023c
  Additional Information 2:    023cde462b8019a6bb5ee8774be2c1ed
  Additional Information 3:    71a7
  Additional Information 4:    71a7e71adb058bb0569b8e144ee76ab0

Related information I took off the internet regarding ntdll.dll:
NTDLL.DLL, FILE DESCRIPTION: NT LAYER DLL
Errors related to ntdll.dll can arise for a few different different reasons.
For instance, a faulty application, ntdll.dll has been deleted or misplaced,
corrupted by malicious software present on your PC or a damaged Windows registry.
This file is required by Windows, and deleting the file would make Windows inoperable.

Frank

  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

Frank,

Thanks for sending the partially created makefile.  It'll provide a starting point for debugging. 

The crash information isn't as useful.  I'd guess it's just explaining that some part of the Windows API was called with an illegal argument or a bad memory address.  The Internet search information is a generic description of why a DLL might cause a crash.  Simply Fortran doesn't ship ntdll.dll as it is a core component of the Windows operating system.

Jeff Armstrong
Approximatrix, LLC
  • jeff
  • Administrator
  • Offline

Re: SF 2.39 Indexing Problem

I believe I've isolated the issue to using prepared statements in our internal database.  Version 2.38 switched to multithreaded dependency and Fortran element scanning. For speed reasons, the internal database prepared insertion and retrieval queries upon startup.  The issue arises when two threads attempt to use the same prepared statement.  If both are, for example, querying the database for available modules at the same time, the two queries can actually start using the same pointer to a query, causing the second-to-finish thread to crash if the first-to-finish thread actually closes out the query.  The issue is more likely to arise as the number of processors on the system increases. 

A fix for 2.40 is now being tested that basically removes the prepared statements entirely since the bottleneck is not the internal database.  Reliability should be significantly increased.

Jeff Armstrong
Approximatrix, LLC

Re: SF 2.39 Indexing Problem

Hi Jeff,

That's great news.  I was concerned that something on my system was causing the problem. I tried turning off the anti-virus, running check-disk, scanning for adware, cleaning up the registry, etc., but none of it prevented the SF 2.39 issue.  I finally had to revert back to SF 2.37.

Now I'm double pleased; first that you found the problem and fixed it and second that it was not my computer causing the problem.

I look forward to using SF 2.40 and as always thanks for your continued support.

Frank