Backtrace Error

[pauld11718]

My Code :

PROGRAM ABCD
WRITE(*,*) 'abcd'
open(1,file='ab.dat')
WRITE(*,*) 'abcd'
END PROGRAM ABCD

Contents of ab.dat
10 15 20

Code Execution Yields:
abcd

Program recieved signal SIGSEGV: Segmenatation fault - invalid memeory reference.

Backtrace for thiss error:
#0 ffffffff

Compiler Downloaded from:
http://tdm-gcc.tdragon.net/download

[abcd]

Unable to understand the reason.....

[Arjen Markus]

Op donderdag 16 juli 2015 08:52:13 UTC+2 schreef pauld11718:

I guess you imply a question and I can guess it, I think, but it would help if you just formulate it.

Regards,

Arjen

[FX]

> Compiler Downloaded from:
> http://tdm-gcc.tdragon.net/download

Please report your compiler's bug to the compiler vendor (above).

--
FX

[pauld11718]

The output of the code shall be:
abcd
abcd

but it's not. Its giving some backtrace error.
I feel the problem is with

open(1,file='ab.dat')

but not sure.
So what can be done to resolve the issue?

[Arjen Markus]

Op donderdag 16 juli 2015 12:31:31 UTC+2 schreef pauld11718:

The program is almost trivial and should simply work. To be sure you can try it with another compiler, but it smells like a problem in the TDM version of the gfortran compiler you used.

Follow the advice by FX, I'd say.

Regards,

Arjen

[FX]

> So what can be done to resolve the issue?

Report your compiler's bug to the compiler vendor
(http://tdm-gcc.tdragon.net/).

In order to save everyone some time, here are canned answers for the next
5 times you ask the same question:

Report your compiler's bug to the compiler vendor
(http://tdm-gcc.tdragon.net/).

Report your compiler's bug to the compiler vendor
(http://tdm-gcc.tdragon.net/).

Report your compiler's bug to the compiler vendor
(http://tdm-gcc.tdragon.net/).

Report your compiler's bug to the compiler vendor
(http://tdm-gcc.tdragon.net/).

Report your compiler's bug to the compiler vendor
(http://tdm-gcc.tdragon.net/).

--
FX

[lyng...@gmail.com]

Just for yucks, I cut-and-pasted the program into a file on my Macintosh, compiled with gfortran, and ran the program. Works as expected.

My gfortran version is 4.90.

Since TDM-GCC re-packages gcc for Windows, you should, as recommended, uh, several times above, contact the vendor. Although unlikely, it could be a bug in later versions.

[Keith Dick]

No, the program probably is not getting a "Backtrace error", as you call it. "Backtrace" is what the fortran runtime library does after an error occurs to show you where in your program the problem occurred. A backtrace usually shows each active subprogram and the line number at which it is executing. Your program contains no subroutine or function calls, so there is not really any backtrace to be done. The backtrace does look a little odd, but I am not familiar with the compiler you are using, so maybe that backtrace is normal. Did you turn on whatever options the compiler offers to enable symbolic debugging? If not, turning them on might cause the backtrace to be a little more friendly, perhaps giving the source file name and line number of the statement that got the error.

As for the error, it is reported just above the backtrace: the program got a SIGSEGV signal, which means it tried to access a memory address which it was not authorized to access. That probably is an indication of a coding error inside the fortran runtime library. The coding error is probably in an execution path that only is taken in an error situation or at least only in a situation that is unusual in some way. Otherwise, you would expect it would have been encountered and fixed by the folks who are offering that compiler. Whatever problem the runtime library encountered, it should have been able to display a sensible error message rather than making an invalid memory reference.

So, what was the situation that made the fortran runtime library get into trouble? You probably are right that it is something about the OPEN statement, although there is a chance that execution did proceed past the OPEN statement successfully. If the output of the second WRITE was buffered by the runtime library and a failure occurred after that point, it might be that the output from the second WRITE just never got flushed to the terminal.

I notice that there is no STOP statement in your program. As I said, I am not familiar with the compiler you are using, but I believe a STOP at the end of the main program is optional, so omitting the STOP ought to be okay, but maybe the compiler you are using has a problem without an explicit STOP statement. So one thing you could try is to add a STOP statement just before the END PROGRAM statement. If that cures the problem, then it probably is an error in the compiler that you should report to the folks who provide that compiler.

I imagine a missing STOP is not the problem, so what else could it be? Certainly, the OPEN statement is an obvious place to look for something unusual. Some fortran products reserve the use of low unit numbers for particular uses, so using unit 1 in the OPEN might be clashing with this fortran product's intent for using unit 1. Try using a unit number greater than 10 to see whether that cures the problem. If that is the problem, the runtime library still has a bug in that it ought to display a proper error message for misuse of unit 1, and it would be good of you to report the problem according to the directions they give on their web site.

Something else that could be wrong with the OPEN statement is that the file being opened is somehow unsuitable. Maybe its name is not spelled exactly the same as how you typed it in the OPEN statement. Also remember that filenames are case-sensitive in some filesystems, so the name in the program should match the uppercase and lowercase letters exactly. Maybe the file you intended to use is not in the current directory, and so it appears to be missing. Maybe the file is there, but its protection does not permit it to be opened in the way the runtime library is trying to open it. If the file is read-only and that OPEN is requesting read-write access by default, that would cause the operating system open call that the fortran library performs to fail. Maybe there is something else about the file that makes it unacceptable to the runtime library. Maybe the runtime library changes the file names to upper case, and your filesystem is case sensitive.

If the runtime library did not have the error that is making it get the segment error, it probably would have printed a message that would make the guessing about what is wrong unnecessary, or at least a lot easier. But without a proper error message, you will have to check all those things, and anything else you can think of that might make the file be not acceptable.

So some things you could try are:
1. Try using unit 20 instead of unit 1.
2. Be sure the file name in the OPEN is spelled exactly as the actual file's name, including matching uppercase and lowercase letters exactly.
3. Be sure the file is in the current working directory in effect when you start the program.
4. Add ACCESS='SEQUENTIAL',ACTION='READ' to the OPEN to see whether the defaults chosen by this fortran product are inappropriate for this file.
5. Unlikely, I think, but try to change the actual file name to all upper case and change the file name in the OPEN to all upper case.

If none of those things get past the problem, I don't know what else to suggest except reporting the problem to the folks who provide that compiler, and maybe switching to a different compiler.

[e p chandler]

Unknown what compiler version and operating system you are using.
However, unit 1 may be pre-connected to the keyboard or display.
Even if that is true, it still looks like a compiler bug.
In order to write a better bug report, it might help to replace unit 1 with unit 10 or unit 20 and try again. Larger unit numbers are less likely to conflict with standard input or standard output.

--- e

[Walt Brainerd]

I have TDM gfortran 5.1.0 64-bit version.
I got the same Seg fault.
Changing the unit # to 21 did not help.
Removing the file ab.dat allowed the program
to run successfully, so it does look like a
problem with the OPEN statement.

The TDM site has complete instructions on how to
file a bug report (see "Bugs" tab).

If you are unwilling to file a bug report,
please let me know and I will.

[Ajit Thakkar]

This problem was resolved for gfortran in the last few days. The most recent build (20150715) at
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/5.x/
works fine while earlier ones for version 5.1 do not.