jeyadev@WRC.XEROX.COM (Surendar Jeyadev) (04/04/91)
Sometime ago there was a spate of articles about problems connected with the unformatted write statement in Sun Fortran 1.3.1. I did not see what the conclusion was, but we seem to be running into a similar problem. The program in question has the following statements: ...... imax = 56 jmax = 22 kmax = 17 write(3) (((array(i,j,k), k=1,kmax), j=1,jmax), i=1,imax) ....... While the version 1.2 did not seem to mind, version 1.3.1 declares a segmentation fault and quits. Using dbx I got signal SEGV (no mapping at the fault address) in w4cp at 0xf76f0724 w4cp+8: ld [%o0 + %o1], %o4 but I do not know what to do with this! The user of this program used to run it on a VAX and the write statement was tailored to take into account the fact that the maximum number of records that could be written is 8191. After playing around a bit with the values of imax, jmax and kmax, I found that the program works fine for small values of the 3 numbers, but crashes when their product reaches a critical value. A simple program that writes out a vector with ....... lmax = <some integer less than declared size of a> write(3) (a(i), l=1,lmax) ....... reveals that the program crashes when lmax reaches 2046. Now the question. Is this well known? I cannot find anything about this in the manuals (such as they are). I understand that the workaround is easy, but, has this been observed/documented? And, since the user depends heavily on unformatted writes, are there any other limitations for unformatted writes? Thanks -- Surendar Jeyadev Internet: jeyadev.wbst128@xerox.com Most books say that the sun is a star. But, somehow, it knows how to change back to a sun in the morning. (5th grader)
edotto@ux1.cso.uiuc.edu (Ed Otto) (04/04/91)
jeyadev@WRC.XEROX.COM (Surendar Jeyadev) writes: >write(3) (((array(i,j,k), k=1,kmax), j=1,jmax), i=1,imax) >....... > >While the version 1.2 did not seem to mind, version 1.3.1 declares >a segmentation fault and quits. Using dbx I got > >signal SEGV (no mapping at the fault address) in w4cp at 0xf76f0724 >w4cp+8: ld [%o0 + %o1], %o4 > >The user of this program used to run it on a VAX and the write >statement was tailored to take into account the fact that the maximum >number of records that could be written is 8191. After playing around >a bit with the values of imax, jmax and kmax, I found that the program >works fine for small values of the 3 numbers, but crashes when their >product reaches a critical value. My bet is that you aren't running into # of record limit so much as a SIZE of record limit... If they are 2 byte integers, you'd be OK...but if 4 byte integers, reals, or otherwise declared, you'd be over the 32767 byte/record limit. Try declaring the arrays to be integer*2. Recompile and call me if I can help in any other way. Ed Otto edotto@uipsuxb.ps.uiuc.edu -- ******************************************************************************** * * Netmail addresses: * * Edward C. Otto III * edotto@uipsuxb.ps.uiuc.edu * * University of Illinois * edotto@uiucux1.cso.uiuc.edu *
khb@chiba.Eng.Sun.COM ((<khb@chiba Keith Bierman fpgroup>)) (04/05/91)
.... question about long records in sun f77v1.3.1
Call your Sun support representative and ask for patch id 100098-03.
In the meantime, try linking -Bstatic.
--
----------------------------------------------------------------
Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043calvin@dinkum.wpd.sgi.com (Calvin H. Vu) (04/05/91)
In <1991Apr4.145658.8389@ux1.cso.uiuc.edu> edotto@ux1.cso.uiuc.edu (Ed Otto) writes: | jeyadev@WRC.XEROX.COM (Surendar Jeyadev) writes: | | >write(3) (((array(i,j,k), k=1,kmax), j=1,jmax), i=1,imax) | >....... | > | >While the version 1.2 did not seem to mind, version 1.3.1 declares | >a segmentation fault and quits. Using dbx I got | > | >signal SEGV (no mapping at the fault address) in w4cp at 0xf76f0724 | >w4cp+8: ld [%o0 + %o1], %o4 | > | >The user of this program used to run it on a VAX and the write | >statement was tailored to take into account the fact that the maximum | >number of records that could be written is 8191. After playing around | >a bit with the values of imax, jmax and kmax, I found that the program | >works fine for small values of the 3 numbers, but crashes when their | >product reaches a critical value. | | My bet is that you aren't running into # of record limit so much as a SIZE of | record limit... | I don't think there is a size of record limit otherwise some of the CAD/CAM vendors who have multi-mega byte records would have to rewrite their programs a long time ago :-). My guesses: 1) There is an enhancement in the new Sun release to recognize pattern such as (array(k), k=1,kmax) as having single step [and hence is contiguous] so the whole block of unformatted data can be written at once instead of one element at a time. 2) There was a bug in the new runtime I/O library so when your unformatted data buffer approaches the 8K size you get a coredump. [i.e. you also have problem if you have "WRITE(3) A" where A is an array of size > 8K] 3) This has already been reported and Sun has fixed it. If you call up its Hotline you may even get a patch. Hey, it's all guessing. - calvin -- ----------------------------------------------------------------------------- Calvin H. Vu | "We are each of us angels with only one Silicon Graphics Computer Systems | wing. And we can only fly embracing calvin@sgi.com (415) 962-3679 | each other."
wang@math.ufl.edu (04/05/91)
In article <1991Apr5.000533.26246@odin.corp.sgi.com>, calvin@dinkum.wpd.sgi.com (Calvin H. Vu) writes: |> I don't think there is a size of record limit otherwise some of |> the CAD/CAM vendors who have multi-mega byte records would have to |> rewrite their programs a long time ago :-). |> |> My guesses: |> |> 1) There is an enhancement in the new Sun release to recognize pattern |> such as (array(k), k=1,kmax) as having single step [and hence |> is contiguous] so the whole block of unformatted data can be written |> at once instead of one element at a time. |> |> 2) There was a bug in the new runtime I/O library so when your |> unformatted data buffer approaches the 8K size you get a coredump. |> [i.e. you also have problem if you have "WRITE(3) A" where A is |> an array of size > 8K] |> |> 3) This has already been reported and Sun has fixed it. If you call |> up its Hotline you may even get a patch. |> |> Hey, it's all guessing. The limitation of 8K maximum record length is a bug of v.1.3.1. You can get a patch from the SUN to fix it.