Bus error ?

[Luciel]

Hi,

I want to make a subroutine that imports matrix array from the
specific txt file such as,

----------------------------------------
n
m
a(1,1) ... a(1,m)
.
.
.
a(n,1)... a(n,m)
---------------------------------------

Compiler doesn't have any problem with my code, but when I run this, I
have bus error,

---------------------------------------
$ ./test3
m n (<- numbers in the file)
Bus error
---------------------------------------

I think it's the problem with handling an allocatable variable and its
dummy variable. Could anyone check my code below, and give me some
advice about this issue? Thanks! =)

PROGRAM test3
IMPLICIT NONE

CHARACTER(len=20) :: File_Name
DOUBLE PRECISION, ALLOCATABLE, DIMENSION(:,:) :: T1

!File_Name='./test/Mr.txt'
CALL IMPORT_MAT(T1,File_Name='sample.txt')

WRITE(*,36) T1(1,:)!(a(i, :), i = 1, n)
WRITE(*,36) T1(2,:)
WRITE(*,36) T1(3,:)
WRITE(*,36) T1(4,:)
WRITE(*,36) T1(5,:)

36 FORMAT(5ES23.15)

END PROGRAM test3

SUBROUTINE IMPORT_MAT(Joos,File_N)

!implicit NONE
CHARACTER(LEN=*), INTENT(IN) :: File_N
DOUBLE PRECISION, INTENT(INOUT), ALLOCATABLE, DIMENSION(:,:) :: Joos
INTEGER :: i
INTEGER :: n , m

OPEN(11, file = File_N )

READ(11, *) n, m
WRITE(*,*) n,m
ALLOCATE(Joos(n, m))

READ(11,35) (Joos(i, :), i = 1, n)

35 FORMAT(5ES23.15)

END SUBROUTINE IMPORT_MAT

[Michael Metcalf]

"Luciel" <joo...@gmail.com> wrote in message
news:fdff8da8-0907-4fbf...@e6g2000prf.googlegroups.com...

> CALL IMPORT_MAT(T1,File_Name='sample.txt')
>
>
> SUBROUTINE IMPORT_MAT(Joos,File_N)
>
> CHARACTER(LEN=*), INTENT(IN) :: File_N

I don't understand how your code can compile. You use a keyword argument but
you don't have an explicit interface, and the names don't match either.
Maybe sort that out first.

Regards,

Mike Metcalf

[Luciel]

On Feb 9, 11:56 pm, "Michael Metcalf" <michaelmetc...@compuserve.com>
wrote:
> "Luciel" <joos...@gmail.com> wrote in message

Thx for the reply. But I don't understand why you think it can't
compile. (And actually it compiles with gfortran very well!) Some of
the lines are commented (by !) not to affect the code as you see, and
I don't know what names you meant, but I think variable names in main
program, and subroutines don't have to match. (Am I wrong?) I think
it's fine as long as their types match.

My main question was that I think Bus error could be caused due to
unaligned memory access, and I want to know how to resolve that issue.
So displaying 'n m' on the screen after running this means it is
fine up to

WRITE(*,*) n,m

line in subroutine, and Bus error could be caused mostly due to the
very next line which is

ALLOCATE(Joos(n, m))

which could be the only cause of Bus error.

Thanks,

J. Lim

[Richard Maine]

Michael Metcalf <michael...@compuserve.com> wrote:

Yes. I wonder what compiler you managed to get this by. G95 says

Error: Procedure with a keyword argument at (1) does not have an
explicit interface

I'll also note that, in addition to the keyword argument isssue, you
need an explicit interface for allocatable dummy arguments and for dummy
arguments with deferred shape. So that's three separate reasons why thsi
code needs an explicit interface. I strongly suspect that this is where
your problem lies... though I'm still surprised you got it to compile at
all.

I generally recommend providing an explicit interface for all
procedures. That avoids having to keep track of all the details of when
they are required.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

[Richard Maine]

Luciel <joo...@gmail.com> wrote:

> On Feb 9, 11:56 pm, "Michael Metcalf" <michaelmetc...@compuserve.com>
> wrote:
> > "Luciel" <joos...@gmail.com> wrote in message
> >
> > news:fdff8da8-0907-4fbf...@e6g2000prf.googlegroups.com...
> >
> > > CALL IMPORT_MAT(T1,File_Name='sample.txt')
> >
> > > SUBROUTINE IMPORT_MAT(Joos,File_N)
> >
> > > CHARACTER(LEN=*), INTENT(IN) :: File_N
> >
> > I don't understand how your code can compile. You use a keyword argument but
> > you don't have an explicit interface, and the names don't match either.
> > Maybe sort that out first.

> Thx for the reply. But I don't understand why you think it can't

> compile. (And actually it compiles with gfortran very well!)

Then I'd submit a bug report on gfortran. That should not compile.

> I think variable names in main
> program, and subroutines don't have to match. (Am I wrong?) I think
> it's fine as long as their types match.

No variable names in the main programn are at issue. It is the keyword
in the actual argument list. That is not a variable, it is an argument
keyword. Specifically, the File_Name= part. What do you think File_name
is supposed to signify here? In any case, what it does signify is a
dummy argument name... except that it isn't the name of a dummy
argument.

> My main question was that I think Bus error could be caused due to
> unaligned memory access, and I want to know how to resolve that issue.

No. I'm quite sure that is not the problem.

> line in subroutine, and Bus error could be caused mostly due to the
> very next line which is
>
> ALLOCATE(Joos(n, m))
>
> which could be the only cause of Bus error.

No. The cause of the bus error is almost certainly the lack of an
explicit interface. Just because you managed to get to that line before
the symptom shows up does *NOT* prove, or even particularly strongly
indicate, otherwise.

You need to either make your subroutine a module procedure, an internal
procedure, or provide an interface block for it.

[James Van Buskirk]

"Richard Maine" <nos...@see.signature> wrote in message
news:1ic2f8c.ljhqpc18wvzwzN%nos...@see.signature...

> Then I'd submit a bug report on gfortran. That should not compile.

Mmmm... this one seems to be killing gfortran big time, unless I'm
also missing something simple. It does indeed compile with -std=f2003
as is with a recent gfortran.

OK, I was missing something simple... I was editing a version in one
directory and compiling a version in another. It is a bug for
gfortran to accept the keyword argument without an explicit interface.
The other stuff is not gfortran's fault, however. Providing an
explicit interface consistent with usage, we get:

C:\gcc_equation\keyword_error>type keyword_error.f90
PROGRAM test3
IMPLICIT NONE

CHARACTER(len=20) :: File_Name
DOUBLE PRECISION, ALLOCATABLE, DIMENSION(:,:) :: T1

interface
subroutine IMPORT_MAT(Joos, File_Name)
CHARACTER(LEN=*), INTENT(IN) :: File_Name

DOUBLE PRECISION, INTENT(INOUT), ALLOCATABLE, DIMENSION(:,:) :: Joos

end subroutine IMPORT_MAT
end interface

!File_Name='./test/Mr.txt'
CALL IMPORT_MAT(T1,File_Name='sample.txt')

WRITE(*,36) T1(1,:)!(a(i, :), i = 1, n)
WRITE(*,36) T1(2,:)
WRITE(*,36) T1(3,:)
WRITE(*,36) T1(4,:)
WRITE(*,36) T1(5,:)

36 FORMAT(5ES23.15)

END PROGRAM test3

SUBROUTINE IMPORT_MAT(Joos,File_N)

!implicit NONE
CHARACTER(LEN=*), INTENT(IN) :: File_N
DOUBLE PRECISION, INTENT(INOUT), ALLOCATABLE, DIMENSION(:,:) :: Joos
INTEGER :: i
INTEGER :: n , m

OPEN(11, file = File_N )

READ(11, *) n, m
WRITE(*,*) n,m

ALLOCATE(Joos(n, m),stat=i)

READ(11,35) (Joos(i, :), i = 1, n)

35 FORMAT(5ES23.15)

END SUBROUTINE IMPORT_MAT

C:\gcc_equation\keyword_error>type sample.txt
5 2
1.0 2.0 3.0
4.0 5.0
6.0 7.0 8.0
9.0 10.0

C:\gcc_equation\keyword_error>C:\gcc_equation\bin\x86_64-pc-mingw32-gfortran
-st
d=f2003 keyword_error.f90 -okeyword_error

C:\gcc_equation\keyword_error>keyword_error
5 2
1.000000000000000E+00 2.000000000000000E+00
3.000000000000000E+00 4.000000000000000E+00
5.000000000000000E+00 6.000000000000000E+00
7.000000000000000E+00 8.000000000000000E+00
9.000000000000000E+00 1.000000000000000E+01

C:\gcc_equation\keyword_error>C:\gcc_equation\bin\x86_64-pc-mingw32-gfortran
-v
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc-4.3-20080208-mingw/configure --host=x86_64-pc-mingw32 --
build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortra
n/gcc-home/binary/mingw32/native/x86_64/gcc/4.3-20080208 --with-gmp=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home
/binary/mingw32/native/x86_64/mpfr --with-sysroot=/home/gfortran/gcc-home/binary
/mingw32/cross/x86_64/gcc/4.3-20080208 --with-gcc --with-gnu-ld --with-gnu-as
--
disable-shared --disable-nls --disable-tls --enable-languages=c,fortran --enable
-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.3.0 20080208 (experimental) (GCC)

So when gfortran is patched up to reject the keyword argument
without an explicit interface it should be good as new.

I think the O.P. is not clear on what the keyword argument is
supposed to do: in the horrible C language, syntax like

IMPORT_MAT(T1,File_Name='sample.txt');

would assign the value of 'sample.txt' to a variable named
File_Name local to the caller. I think that means actually
the File_Name might get assigned the address of a constant
string stored in memory someplace, hopefully it would be a
pointer variable; maybe that's even illegal in C and would
only make sense in C++ where assignment can be overloaded.

In Fortran, however, the statement

CALL IMPORT_MAT(T1,File_Name='sample.txt')

means something completely different. It means that the actual
argument 'sample.txt' is to be associated with the dummy
argument called File_Name. Actually we have used an interface
block to so that the name the caller sees is File_Name even though
the name inside of subroutine IMPORT_MAT is still File_N. This
name, File_Name, has nothing to do with the variable File_Name
local to program test3. Hope that I was able to help more than
to confuse.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[Luciel]

Thanks for all of your helps! I didn't try anything yet, but I think
it will help a lot. I apologize for the lack of my knowledge. Actually
I don't use Fortran that much and need to use it for my recent
research. I am happy that it could be a good chance for me to learn
much more things on coding.

Thanks,

J Lim

[Luciel]

I read through all threads again, and I got the point. Thank you all
so much for helping me. =)

[Thomas Koenig]

On 2008-02-10, James Van Buskirk <not_...@comcast.net> wrote:

> It is a bug for
> gfortran to accept the keyword argument without an explicit interface.

*snarf*

This was the sound of this bug hitting the bugzilla database :-)
Now http://gcc.gnu.org/PR35157 .

[robin]

"Luciel" <joo...@gmail.com> wrote in message
news:fdff8da8-0907-4fbf...@e6g2000prf.googlegroups.com...
> Hi,

>
> Compiler doesn't have any problem with my code, but when I run this, I
> have bus error,
>
> ---------------------------------------
> $ ./test3
> m n (<- numbers in the file)
> Bus error
> ---------------------------------------
>
> I think it's the problem with handling an allocatable variable and its
> dummy variable. Could anyone check my code below, and give me some
> advice about this issue? Thanks! =)

The problem is that you have separate program units
without a specific interface.

You should try compiling your program this way,
and then your compiler will be able to diagnose
any errors that it finds.

PROGRAM test3
IMPLICIT NONE

CHARACTER(len=20) :: File_Name
DOUBLE PRECISION, ALLOCATABLE, DIMENSION(:,:) :: T1

!File_Name='./test/Mr.txt'
CALL IMPORT_MAT(T1,File_Name='sample.txt')

WRITE(*,36) T1(1,:)!(a(i, :), i = 1, n)
WRITE(*,36) T1(2,:)
WRITE(*,36) T1(3,:)
WRITE(*,36) T1(4,:)
WRITE(*,36) T1(5,:)

36 FORMAT(5ES23.15)

CONTAINS

SUBROUTINE IMPORT_MAT(Joos,File_N)

!implicit NONE
CHARACTER(LEN=*), INTENT(IN) :: File_N
DOUBLE PRECISION, INTENT(INOUT), ALLOCATABLE, DIMENSION(:,:) :: Joos
INTEGER :: i
INTEGER :: n , m

OPEN(11, file = File_N )

READ(11, *) n, m
WRITE(*,*) n,m
ALLOCATE(Joos(n, m))

READ(11,35) (Joos(i, :), i = 1, n)

35 FORMAT(5ES23.15)

END SUBROUTINE IMPORT_MAT
END PROGRAM test3