crash report 
Author Message
 crash report

while i am doing a loop, after some loop, i am getting crash report
like:
open: can't stat file
apparent state: unit 1 named /home/Rudra/Recursion/ASR/CHECK_A
lately writing sequential formatted external IO
*** glibc detected *** free(): invalid pointer: 0x0000002a9569d580 ***
IOT Trap

what is that? how can i fix it?



Wed, 24 Aug 2011 14:27:06 GMT  
 crash report

Quote:
> while i am doing a loop, after some loop, i am getting crash report
> like:
> open: can't stat file
> apparent state: unit 1 named /home/Rudra/Recursion/ASR/CHECK_A
> lately writing sequential formatted external IO
> *** glibc detected *** free(): invalid pointer: 0x0000002a9569d580 ***
> IOT Trap

> what is that? how can i fix it?

ok, some more information: this is related to the problem posted by me
in synchronisation of two executable. there i have applied a lock. so
am lot getting why it is crashing. plz help


Wed, 24 Aug 2011 14:28:55 GMT  
 crash report

Quote:

> while i am doing a loop, after some loop, i am getting crash report
> like:
> open: can't stat file
> apparent state: unit 1 named /home/Rudra/Recursion/ASR/CHECK_A
> lately writing sequential formatted external IO
> *** glibc detected *** free(): invalid pointer: 0x0000002a9569d580 ***
> IOT Trap
> what is that? how can i fix it?

This usually comes from going outside the bounds of an
array, likely a dynamically allocated one.  You write over the
free list (list of memory available to be allocate), and then next
allocate or free that uses that entry fails.

Turn on bounds checking.

-- glen



Wed, 24 Aug 2011 15:41:05 GMT  
 crash report

Quote:

> while i am doing a loop, after some loop, i am getting crash report
> like:
> open: can't stat file
> apparent state: unit 1 named /home/Rudra/Recursion/ASR/CHECK_A
> lately writing sequential formatted external IO
> *** glibc detected *** free(): invalid pointer: 0x0000002a9569d580 ***
> IOT Trap

> what is that? how can i fix it?

You cannot use unit 1 as a file on disk in most run-time compiled
fortran code.
In general, do not use units 0 through 3 and it is wiser to not use 4
to 6 either.

So fix your file unit numbers to be above 6 and try again.
My own compiler will accept 4, 5 and 6, but 5 was historically card
input and 6 was pronter output (note: a long time ago). And also '0'
or '*' is the keyboard/screen combination



Wed, 24 Aug 2011 17:26:03 GMT  
 crash report

Quote:

>You cannot use unit 1 as a file on disk in most run-time compiled
>Fortran code.
>In general, do not use units 0 through 3 and it is wiser to not use 4
>to 6 either.

The first statement is dubious, to put it mildly, and the second is
not reliable.  In my exploration of recent compilers, I have found
the use of units 5 and 6 for INPUT_UNIT and OUTPUT_UNIT to be more
common than units 1 and 2, or 0 and 1.  Not enough to regard it as
a reliable rule, of course, but enough for some people to get away
with assuming it in 'portable' programs.  I haven't seen any of the
other zillion conventions recently, but they may still be around.

The safest rule is to use INQUIRE to check if a unit is connected
(i.e. using OPENED), but a good rule for modern systems is to use
only units 11-99.  That wasn't reliable 20 years ago, but I haven't
found a system where it isn't, recently.

Quote:
>So fix your file unit numbers to be above 6 and try again.
>My own compiler will accept 4, 5 and 6, but 5 was historically card
>input and 6 was pronter output (note: a long time ago). And also '0'
>or '*' is the keyboard/screen combination

No, it isn't.  There have been systems where it was, but it is very
dubiously conforming to Fortran 2003 to use the same unit number for
INPUT_UNIT and OUTPUT_UNIT (what you call the keyboard and screen,
respectively).

And there certainly are systems which use the Unix numbering, so
INPUT_UNIT, OUTPUT_UNIT and ERROR_UNIT are 0, 1 and 2.

Regards,
Nick Maclaren.



Wed, 24 Aug 2011 19:41:48 GMT  
 crash report

Quote:


> >You cannot use unit 1 as a file on disk in most run-time compiled
> >Fortran code.
> >In general, do not use units 0 through 3 and it is wiser to not use 4
> >to 6 either.


> No, it isn't.  There have been systems where it was, but it is very
> dubiously conforming to Fortran 2003 to use the same unit number for
> INPUT_UNIT and OUTPUT_UNIT (what you call the keyboard and screen,
> respectively).

Rubbish! There still are today and will be in the future Fortran
compilers where 0 or "*"  used as a unit number mean "screen and
keyboard". Mind you, the very  first compilers didn't, but all mine
do.

Exact quote from one of my Fortran manuals

" * represents the keyboard and screen, a sequential formatted file,
also known as unit zero".

And that was the first line in the chapter on files and  I/O !!!

You can talk about UNIX and F2003 and so on, but the average just-come-
to-Fortran user won't know and won't care about the exceptions or even
(probably) 2003 and later compiler versions, and not only because so
many cost more that the new computers they are using (shame!).

 I certainly don't and there just may be one person reading this Forum
with more years of using Fortran. I'll always grant there are many who
know far more about the current compilers that I don't need to use (I
have Intel 9.0 as my latest).

CVF/DFV and Intel compilers all accept unit 0 or the asterisk  as do
all the (Intel-based) compilers. As for the other abbove guidlines of
mine; these are the same suggestions made by many experienced Forum
posters over the years - "don't use 1 to 6 as unit numbers, but
especially not 1 to 3".
And when I sugested not use unit zero, I really meant in the sense of
don't specifically OPEN a file as unit zero (I used unit "0"  instead
of "*" by habit until quite recently).

If I ever say something works it's because I'm using it. And youl'd
better believe it's in the manual that goes with the compiler as well.
I doubt if "INPUT_UNIT" appears in any of the Fortran manuals I have -
certainly not in the index of three and the bodies of two (the third
is three inches thick and I'm not disposed to check every one of the
page any further).

Don't nit-pick - try to help the new user!



Thu, 25 Aug 2011 12:59:45 GMT  
 crash report

Quote:

>> >You cannot use unit 1 as a file on disk in most run-time compiled
>> >Fortran code.
>> >In general, do not use units 0 through 3 and it is wiser to not use 4
>> >to 6 either.


>> No, it isn't.  There have been systems where it was, but it is very
>> dubiously conforming to Fortran 2003 to use the same unit number for
>> INPUT_UNIT and OUTPUT_UNIT (what you call the keyboard and screen,
>> respectively).

>Rubbish! There still are today and will be in the future Fortran
>compilers where 0 or "*"  used as a unit number mean "screen and
>keyboard". Mind you, the very  first compilers didn't, but all mine
>do.

Sigh.  I will give you credit for snipping incorrectly, rather than
deliberately misquoting.  The paragraph of yours that I included
immediately before my response and to which I was replying read:

    >So fix your file unit numbers to be above 6 and try again.
    >My own compiler will accept 4, 5 and 6, but 5 was historically card
    >input and 6 was pronter output (note: a long time ago). And also '0'
    >or '*' is the keyboard/screen combination

Despite your claimed experience, I continue to be flabberghasted
at your readiness to assume that the behaviour that you have seen
applies universally.  The fact that some compilers do something does
not mean that it is conforming - or will even continue - the need
to double backslashes is a prime example, and there were lots more
in earlier eras (e.g. DCMPLX and 'Q' for quadruple precision).

Quote:
>CVF/DFV and Intel compilers all accept unit 0 or the asterisk  as do
>all the (Intel-based) compilers. As for the other abbove guidlines of
>mine; these are the same suggestions made by many experienced Forum
>posters over the years - "don't use 1 to 6 as unit numbers, but
>especially not 1 to 3".

And gfortran, Sun ONE Studio, NAG and Pathscale don't.  I can't be
bothered to chase around for more.

Note that a rather more common convention for unit 0 is for error
messages (i.e. stderr), so writing to it is a lot more likely to
work than reading from it.

Quote:
>And when I sugested not use unit zero, I really meant in the sense of
>don't specifically OPEN a file as unit zero (I used unit "0"  instead
>of "*" by habit until quite recently).

That clearly demonstrates that you use only a few compilers.  Even
today, I use three regularly, and more on occasion.

Regards,
Nick Maclaren.



Thu, 25 Aug 2011 17:58:12 GMT  
 crash report

Quote:

> CVF/DFV and Intel compilers all accept unit 0 or the asterisk  as do
> all the (Intel-based) compilers. As for the other abbove guidlines of
> mine; these are the same suggestions made by many experienced Forum
> posters over the years - "don't use 1 to 6 as unit numbers, but
> especially not 1 to 3".
> And when I sugested not use unit zero, I really meant in the sense of
> don't specifically OPEN a file as unit zero (I used unit "0"  instead
> of "*" by habit until quite recently).

I think we have had this discussion about trying to use unit 0 for both
input and output before. Don't do it.

C:\Temp>type test1.f
        read(0,100) i
        write(0,100) i
100    format (i4)
        end

C:\Temp>gfortran test1.f

C:\Temp>a
At line 1 of file test1.f
Fortran runtime error: Cannot read from file opened for WRITE

C:\Temp>

C:\Temp>ifort test1.f
Intel(R) Visual Fortran Compiler for applications running on IA-32,
Version 10.1
     Build 20070913 Package ID: w_fc_p_10.1.011
Copyright (C) 1985-2007 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:test1.exe
-subsystem:console
test1.obj

C:\Temp>test1
forrtl: The handle is invalid.
forrtl: severe (39): error during read, unit 0, file CONOUT$
Image              PC        Routine            Line        Source
test1.exe          00456CBA  Unknown               Unknown  Unknown
test1.exe          00454575  Unknown               Unknown  Unknown
test1.exe          0040B612  Unknown               Unknown  Unknown
test1.exe          0040B149  Unknown               Unknown  Unknown
test1.exe          0040294D  Unknown               Unknown  Unknown
test1.exe          00401047  Unknown               Unknown  Unknown
test1.exe          0045D151  Unknown               Unknown  Unknown
test1.exe          00441C9C  Unknown               Unknown  Unknown
kernel32.dll       7C817067  Unknown               Unknown  Unknown

C:\Temp>



Thu, 25 Aug 2011 23:45:01 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Reports with many graphics crashes!!

2. Program crash in Report Writer procedure C5RW.exe using applications produced with CLARION 5.000.00

3. Crash in Report Writer C5RW

4. Crash before printing report

5. Ni reports crashes with large amounts of data

6. TclGlobalEval() with static string goes crash on a Sun (bug report)

7. Ariane Crash (Was: Adriane crash)

8. db Reports - include premade reports with your program

9. Report Writer, Crystal Reports

10. Report Copies / multi-page report

11. exporting report procedure to report writer

 

 
Powered by phpBB® Forum Software