Mysterious Crash with g95

3 views
Skip to first unread message

Stan

unread,
Sep 21, 2009, 10:45:42 AM9/21/09
to gg95
I have an interesting set of code that crashes when called. The
offending subroutine is findx.f. The full program uses subroutine
findx and an entry to findxc. The call to findx works, but the entry
to findxc crashes. I have simplified this test case to an abbreviated
the code in the main program and the subroutine geomar.f. I placed
some write(0,*) statements to see where the program crashes. When I
run the test program I get the following results when executing test-
nata.a. For this simplified case the pause statement is honored, but
for the full program it is not, but crashes anyway. The options for
the compiling are:
G95OPTS = -fzero -fstatic -fonetrip -r8 -i8 -ftrace=full
---------------------------------------------------

test-nata.a
findx entered findxc A= 19.05 MBL= 2 X= 0.
PAUSE statement executed. Hit Return to continue

Bus error

--------------------------------------------------
my simplified code is
main.f
c main program for the test
A = 19.05
MBL = 2
XMOD = 0.
call FINDXC(A,MBL,XMOD)
write(6,*)' end of this test'
end
geomar.f
SUBROUTINE GEOMAR (X,ARATIO,DERIVA)
C COMPUTES GEOMETRIC AREA RATIO ARATIO AND ITS DERIVATIVE DERIVA.
CHARACTER*6 RNAME
DATA RNAME /'GEOMAR'/
IENTRY=1
write(0,*)' geomar entered GEOMAR'
write(0,*)' geomar X=',X,' ARATIO=',ARATIO,' DERIVA=',DERIVA
GO TO 10
ENTRY GMAR(X,Y)
IENTRY=2
write(0,*)' geomar entered GMAR'
write(0,*)' geomar X=',X,' Y=',Y
GO TO 10
ENTRY GMAR2(X,Y,Z)
IENTRY=3
write(0,*)' geomar entered GMAR2'
write(0,*)' geomar X=',X,' Y=',Y,' Z=',Z
GO TO 10
ENTRY GMAR3(X,DYDX,DZDX,Y,Z)
IENTRY=4
write(0,*)' geomar entered GMAR3'
write(0,*)' geomar X=',X,' DYDX=',DYDX,' DZDX=',DZDX,' Y=',Y,'
Z=',Z
10 CONTINUE
180 RETURN
END
findx.f
SUBROUTINE FINDX (A,UPDOWN,X)
C IMPLICIT DOUBLE PRECISION (A-H,O-Z)
LOGICAL ERR,UPPER
C SOLVES GEOMETRIC AREA RELATION FOR X, GIVEN THE VALUE A(X).
C A=GEOMETRIC AREA RATIO (=1.0 AT GEOMETRIC THROAT)
C UPDOWN=1. IF DOWNSTREAM SOLUTION IS DESIRED
C =-1. IF UPSTREAM SOLUTION IS DESIRED
C X=VALUE OF X OBTAINED
C ENTRY FINDXC SOLVES FOR X AT WHICH THE MBL-TH PROFILE HAS
A
C HALF-WIDTH OF A.
COMMON /ERROR/ ERR
DIMENSION Z(2),DZDX(2)
CHARACTER*6 RNAME(2)
DATA RNAME /'FINDX ','FINDXC'/
IENTRY=1
write(0,*)' findx entered A=',a,' UPDOWN=',UPDOWN,' X=',x
GO TO 10
ENTRY FINDXC(A,MBL,X)
write(0,*)' findx entered findxc A=',a,' MBL=',mbl,' X=',x
pause
IENTRY=2
UPDOWN=1.
N=0
V=100.
write(0,*)' findx entered findxc A=',a,' MBL=',mbl,' X=',x
pause
GO TO 60
10 N=0
V=1.
write(0,*)' findx @ 10'
IF (ABS(A-1.0).LT.1.E-5) GO TO 40
IF (A-1.) 20,40,50
20 WRITE (6,170) A
30 CALL DUMP (RNAME(IENTRY))
40 X=0.
RETURN
50 VL=0.
ERRL=1.-A
UPPER=.FALSE.
ERRU=1.E30
write(0,*)' findx NEWTON-RAPHSON ITERATION TO SOLVE FOR X'
write(0,*)' findx ERRL=',ERRL,' UPPER=',UPPER,' ERRU=',ERRU
C NEWTON-RAPHSON ITERATION TO SOLVE FOR X
60 N=N+1
write(0,*)' findx N=',n,' IENTRY=',IENTRY
IF (N.LE.50) GO TO 70
WRITE (6,180) A,UPDOWN,IENTRY,MBL
WRITE (6,*) 'V = ', V
WRITE (6,*) 'AR = ', AR
WRITE (6,*) 'DADX = ', DADX
WRITE (6,*) 'VO = ', VO
WRITE (6,*) 'VL = ', VL
WRITE (6,*) 'VU = ', VU
WRITE (6,*) 'ERRL = ', ERRL
WRITE (6,*) 'ERRU = ', ERRU
WRITE (6,*) 'ERR = ', ERR
WRITE (6,*) 'UPPER = ', UPPER
GO TO 30
70 GO TO (80,130), IENTRY
80 CALL GEOMAR (SIGN(V,UPDOWN),AR,DADX)
IF (ERR) RETURN
ERA=AR-A
IF (ERA) 90,160,110
90 IF (ERA-ERRL) 140,140,100
100 ERRL=ERA
VL=V
GO TO 140
110 UPPER=.TRUE.
IF (ERA-ERRU) 120,140,140
120 ERRU=ERA
VU=V
GO TO 140
c130 CALL GMAR3 (V,DZDX(1),DZDX(2),Z(1),Z(2))
130 continue
if(IENTRY.eq.2) then
write(0,*)' findx at 130 calling GMAR3'
endif
CALL GMAR3 (V,DZDX(1),DZDX(2),Z(1),Z(2))
if(IENTRY.eq.2) then
write(0,*)' findx exited GMAR3'
endif
AR=Z(MBL)
DADX=DZDX(MBL)
140 IF (ABS(1.-AR/A).LE.1.E-5) GO TO 160
IF (N.LE.10) GO TO 150
IF (IENTRY.EQ.2.OR..NOT.UPPER) GO TO 150
V=VL-(VU-VL)*ERRL/(ERRU-ERRL)
GO TO 60
150 VO=V
V=V+(A-AR)/ABS(DADX)
V=DMIN1(V,2.*VO)
GO TO 60
160 X=SIGN(V,UPDOWN)
RETURN
C
170 FORMAT(//,' FINDX CALLED WITH AN AREA RATIO LESS THAN UNITY,',
10X,
1'A=',E15.8)
180 FORMAT (//,' MORE THAN 50 ITERATIONS IN FINDX',
10X,'A=',D15.8,10X,
1'UPDOWN=',F3.0,10X,'IENTRY=',I2,10X,'MBL=',I2)
END

Stan

unread,
Sep 21, 2009, 11:03:02 AM9/21/09
to gg95
I forgot to mention I am on a Mac OS X 10.5.8 and g95 from fink.

jfh

unread,
Sep 21, 2009, 11:02:15 PM9/21/09
to gg95
I found that g95 objected at compile time to

30 CALL DUMP (RNAME(IENTRY))

because DUMP is not an intrinsic subroutine and there is no subroutine
DUMP declaration in the program given. We need complete examples to
test for possible compiler bugs!

John Harper

Stan

unread,
Sep 22, 2009, 9:27:39 AM9/22/09
to gg95
Sorry - here it is

dump.f
SUBROUTINE DUMP (RNAME)
CHARACTER*6 RNAME
LOGICAL ERR
COMMON /ERROR/ ERR
ERR=.TRUE.
WRITE (6,10)char(12), RNAME
RETURN
C
10 FORMAT (a,' DUMP ROUTINE CALLED BY ',A6)
END

Stanley Williams

unread,
Sep 22, 2009, 9:36:30 AM9/22/09
to gg...@googlegroups.com, john....@vuw.ac.nz
Sorry,
I posted the dump subroutine just a few minutes ago.
Stan

John McFarland

unread,
Sep 22, 2009, 12:08:59 PM9/22/09
to gg95
Stan,

I was able to reproduce your problem on Linux. It gave gdb some
trouble, but it looks like the crash is associated with the access to
the variable UPDOWN after entry though FINDXC. If I add a line
immediately after your pause statement to print the value of UPDOWN,
it crashes there. I'm not familiar with ENTRY statements, so I don't
know whether this is a compiler bug or something wrong with the
program. Either way, the issue may be related to the fact that UPDOWN
is a dummy argument to FINDX and is also accessed when entering
through FINDXC. You might try rewriting the program to not use the
ENTRY statement or maybe define UPDOWN in both entry points.

John

On Sep 22, 8:36 am, Stanley Williams <sdw2...@earthlink.net> wrote:
> Sorry,
> I posted the dump subroutine just a few minutes ago.
> Stan
>

Stan

unread,
Sep 22, 2009, 12:46:59 PM9/22/09
to gg95
John
Thanks,
The ENTRY statement may only be used within subroutine and function
subprograms and provides for multiple entry points into these
procedures. The form of an ENTRY statement is the same as that for a
SUBROUTINE statement except that the keyword ENTRY is used. An ENTRY
statement may not occur within any block structure.
I checked to see if changing UPDOWN to the calling statement helps,
and it did. Now I will see how it works in the big program. VERY OLD
CODE !!!
Stan

Jimmy

unread,
Sep 23, 2009, 4:55:52 AM9/23/09
to gg...@googlegroups.com
It is a program bug. It is not permissible to change a dummy argument in
any ENTRY or SUBROUTINE statement other than the actual ENTRY or SUBROUTINE
statement used - unless the same dummy argument is in both.

Jimmy.

----- Original Message -----
From: "John McFarland" <john.mc...@swri.org>
To: "gg95" <gg...@googlegroups.com>
Sent: Tuesday, September 22, 2009 5:08 PM
Subject: Re: Mysterious Crash with g95

Stan,

I was able to reproduce your problem on Linux. It gave gdb some
trouble, but it looks like the crash is associated with the access to
the variable UPDOWN after entry though FINDXC. If I add a line
immediately after your pause statement to print the value of UPDOWN,
it crashes there. I'm not familiar with ENTRY statements, so I don't
know whether this is a compiler bug or something wrong with the
program. Either way, the issue may be related to the fact that UPDOWN
is a dummy argument to FINDX and is also accessed when entering
through FINDXC. You might try rewriting the program to not use the
ENTRY statement or maybe define UPDOWN in both entry points.

John

On Sep 22, 8:36 am, Stanley Williams <sdw2...@earthlink.net> wrote:
> Sorry,
> I posted the dump subroutine just a few minutes ago.
> Stan
>
>

<cut>

Reply all
Reply to author
Forward
0 new messages