A Debugging Question.

Don,

There can be some oddities surrounding the startup code of Fortran programs, generally speaking.  I see this behavior on occasion with free-format Fortran as well.  When the debugger starts up, it pauses at the "main" program unit. Usually the underlying debugger correctly flags your program unit as the proper start point.  However, under some circumstances, it mistakes a procedure called "main" that you didn't write; it's actually part of the Fortran startup code (and is referring to the C "main" procedure in the underlying Fortran startup code).  It will still report the proper file, so you end up with it occasionally doing what you describe as the debugger actually enters the proper Fortran procedure.

It's an odd behavior that I've looked into before.  I obviously don't have a good fix or a handle on the circumstances that lead to the behavior.

Do you have "Enable Runtime Diagnostics" turned on?

It is best to disable this when you are debugging as it can cause the current line to "Jump about".

The SIGSEGV error is probably a bug in your coding. Try using the option -fbacktrace and debugging -g  to find out where it is occurring.

-heap-arrays is an Intel (ifort) compiler option for putting automatic arrays on the heap instead of the stack. Gfortran doesn't have this option because it always puts automatic arrays on the heap (not the stack).

See:

http://jblevins.org/log/segfault

Don,  I too have been (and still am) plagued with a SIGSEGV error when using the debugger, which I get ONLY from inside the debugger.

I am fairly sure it is a DBG fault, so not something that Jeff can solve.  It has brought my project development to a complete standstill while I wait in hope for a solution in a DBG UPDATE.

I've 'touched' the topic thread on this, to bring it to the top of the current list (just below this topic) in case you want to have a quick look.  See especially page 2 of the thread.
---
John

Don,

The development version now contains some speed improvements to the debugger's processing of variable updates.  It should be substantially faster in most cases.  On my test program, I notice a 2x to 5x speedup (estimated, of course) stepping in a relatively complicated and variable-rich procedure.  Your speed improvement could theoretically be significantly better after the program starts up and the variables panel is populated.

SIGSEGV fault is a program development killer.
I long to see the back of it.

Just some random thoughts.  I'm sure you'll have considered far more than these already . . ...

Are the error conditions which might arise capable of being found by explicit tests for each one (such as non-existent files, files already in use, and so forth)?  You could then omit the "ierr=0" part of the offending statement.

Alternatively, is there anything strange lurking at the end of any previous lines, possibly off-screen to the right, which might be triggering the trip, quite misleadingly, on the "ierr=0" line?
---
J.

Don,

If you're comfortable with doing so, you can email the source code to me, and I can have a look/try to run it on my end.  I can't explain why you're seeing the SIGSEGV from your description.

With respect to DFLIB and KERNEL32, both are unlikely to make an appearance in Simply Fortran.  DFLIB is pretty big, there would at least be a chance to port it.  However, it is rather unlikely, especially because many of its more commonly used features are superseded by Fortran 2003 and 2008 intrinsics.  KERNEL32 was part of Digital's/Compaq's/HP's port of the Windows API directly to Fortran.  It is only one of a set of libraries (along with USER32, GDI32, COMCTL32...) that are part of the port.  Approximatrix has no plans to provide access to the Windows API from Fortran directly, especially because it gets a bit messy if you try to do so in a standards-compliant manner (Digital/Compaq/HP took some liberties with how Windows pointers are sized and assumed 32-bit, for example).

Don,

Have you tried initialising variables right at the start of the program - even those which should not need initialising yet?
I don't know if doing so would have this effect but my thought is that, as SIGSEGV faults appear to be something to do with accidentally trying to use memory which the executable does not own, this might force the compiler to allocate memory to variables from the very outset?
---
John

Okay, I'm pretty sure the problem centers around the way Compac and gFortran handle structures. I re-wrote a part of the program to make it compatible with gFortran and it got rid of the SIGSEGV error.

And on to another question: (quit sighing, Jeff)  In Fortran IV, you could put a backslash (\) at the end of a format statement to tell the printer not to issue a carriage return/line feed.  In other words, don't advance the printer.  gFortran doesn't like this.  I was told that you could enter 'advance=no' in place of the backslash to kill the CR/LF.  Unfortunately, all it does is print "advance=no" followed by a CR/LF.  Is there an equivalent to the backslash? 

Also, is there a good, general purpose Programmer's Guide that covers the basic fortran commands - not compiler options, etc. that would be helpful to me? 

Don

Thanks, John.  No - I haven't been able to find just a basic programmer's guide to gfortran.  Everything I look at seem to be oriented to command line options, etc.  If you know where to find one, I'd really appreciate it.

The use of Advance goes in the read or write statement, not the format statement

Example of non-advancing IO:

character(len=20) :: name
write(*, 10, advance='no') 'Enter your name: '
read(*, 10) name
write(*, 10, advance='no') 'Hello '
write(*, 10, advance= 'no') name
write(*, 10) ", how are you?"
10 Format (A)

Sorry not to have replied sooner but I'm pleased to see others have given excellent help.
For fortran manuals and references, search the web, not for 'GFortran', because that will just find references on the compiler extensions, compile-time switches and options etc, but for 'Fortran 95', 'Fortran 98', 'Fortran 2003', etc, where you'll find Fortran language references.
---
John