Stackdump issues 
Author Message
 Stackdump issues

Can someone please tell me how I can stop my executable producing  a
stackdump (instead of a proper output file) while  refusing to read from
the input data file. Where could the problem be?

Many thanks



Thu, 27 Nov 2008 19:20:45 GMT  
 Stackdump issues
Hello,

Quote:

> Can someone please tell me how I can stop my executable producing  a
> stackdump (instead of a proper output file) while  refusing to read from
> the input data file. Where could the problem be?

Try putting an iostat= with an integer variable on the read.
Then print the value of the variable, and see what the documentation
says the value means.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.



Thu, 27 Nov 2008 20:43:02 GMT  
 Stackdump issues

Quote:


> > Can someone please tell me how I can stop my executable producing  a
> > stackdump (instead of a proper output file) while  refusing to read from
> > the input data file. Where could the problem be?

> Try putting an iostat= with an integer variable on the read.
> Then print the value of the variable, and see what the documentation
> says the value means.

In my experience, this is exactly the opposite of how to get good
diagnostic data about an I/O error. I've been known to take the IOSTAT=
off of an I/O statement because the iostat= gives only a numeric value,
which you might or might not be able to find anything at all about in
the docs; if you find anything, it will only be pretty general. But if
you take the iostat= off, you get an actual error message, sometimes
with details. I look forward to the iomsg= specifier of f2003 to solve
this, allowing me to do my own error handling and still get at the
system's error message instead of just a numeric code.

I'm afraid I don't have any useful advice for the OP except that he has
not provided enough data. If he is really getting just a stack dump,
without an error message, then fiddling with iostat= isn't likely to
change anything. The possibilities are too numerous to list; that's not
much different from "the program didn't work correctly". If he did
actually get an error message, then he sure needs to tel us what it was.

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



Fri, 28 Nov 2008 00:17:34 GMT  
 Stackdump issues
Hi guys
Back again:
I have run the executable once again and on a secondary output file I get
this message:

list in : end of file
apparent state: unit 50 named fort.50
last format :list io
lately reading direct formatted external IO
0

It would appear that the source of problem is the confused EOF character.
(Is there anything specific on this issue?).

Also reference to formatted external IO is puzzling as this did not present
any previous obstacle.

I hope this clears the iostat issue !??

Many thanks for any feedback.


Quote:


>> > Can someone please tell me how I can stop my executable producing  a
>> > stackdump (instead of a proper output file) while  refusing to read
>> > from
>> > the input data file. Where could the problem be?

>> Try putting an iostat= with an integer variable on the read.
>> Then print the value of the variable, and see what the documentation
>> says the value means.

> In my experience, this is exactly the opposite of how to get good
> diagnostic data about an I/O error. I've been known to take the IOSTAT=
> off of an I/O statement because the iostat= gives only a numeric value,
> which you might or might not be able to find anything at all about in
> the docs; if you find anything, it will only be pretty general. But if
> you take the iostat= off, you get an actual error message, sometimes
> with details. I look forward to the iomsg= specifier of f2003 to solve
> this, allowing me to do my own error handling and still get at the
> system's error message instead of just a numeric code.

> I'm afraid I don't have any useful advice for the OP except that he has
> not provided enough data. If he is really getting just a stack dump,
> without an error message, then fiddling with iostat= isn't likely to
> change anything. The possibilities are too numerous to list; that's not
> much different from "the program didn't work correctly". If he did
> actually get an error message, then he sure needs to tel us what it was.

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



Fri, 28 Nov 2008 17:26:27 GMT  
 Stackdump issues
Hello,

Quote:

> Hi guys
> Back again:
> I have run the executable once again and on a secondary output file I get
> this message:

> list in : end of file
> apparent state: unit 50 named fort.50
> last format :list io
> lately reading direct formatted external IO
> 0

> It would appear that the source of problem is the confused EOF character.
> (Is there anything specific on this issue?).

If the record is supposed to be formatted, the processor might not
be able to read an arbitrary control character.  You might try reading
as an unformatted record and converting manually.

<snip the rest>

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.



Fri, 28 Nov 2008 19:07:39 GMT  
 Stackdump issues

Quote:

> Hi guys
> Back again:
> I have run the executable once again and on a secondary output file I get
> this message:

> list in : end of file
> apparent state: unit 50 named fort.50
> last format :list io
> lately reading direct formatted external IO
> 0

> It would appear that the source of problem is the confused EOF character.
> (Is there anything specific on this issue?).

> Also reference to formatted external IO is puzzling as this did not present
> any previous obstacle.

The message appears to say this file was being read with ACCESS='DIRECT'
  which would account for problems with endfile detection.
Interchangeability of direct and sequential access is probably not a
portable assumption.


Fri, 28 Nov 2008 19:19:46 GMT  
 Stackdump issues


Quote:
> Hi guys
> Back again:
> I have run the executable once again and on a secondary output file I get
> this message:

> list in : end of file
> apparent state: unit 50 named fort.50
> last format :list io
> lately reading direct formatted external IO
> 0

> It would appear that the source of problem is the confused EOF character.
> (Is there anything specific on this issue?).

fortran does not use an EOF character.  Rather, it relies on the OS to tell
it when and end of file condition or an end of record condition exists.

Jim

Quote:

> Also reference to formatted external IO is puzzling as this did not
> present any previous obstacle.

> I hope this clears the iostat issue !??

> Many thanks for any feedback.





>>> > Can someone please tell me how I can stop my executable producing  a
>>> > stackdump (instead of a proper output file) while  refusing to read
>>> > from
>>> > the input data file. Where could the problem be?

>>> Try putting an iostat= with an integer variable on the read.
>>> Then print the value of the variable, and see what the documentation
>>> says the value means.

>> In my experience, this is exactly the opposite of how to get good
>> diagnostic data about an I/O error. I've been known to take the IOSTAT=
>> off of an I/O statement because the iostat= gives only a numeric value,
>> which you might or might not be able to find anything at all about in
>> the docs; if you find anything, it will only be pretty general. But if
>> you take the iostat= off, you get an actual error message, sometimes
>> with details. I look forward to the iomsg= specifier of f2003 to solve
>> this, allowing me to do my own error handling and still get at the
>> system's error message instead of just a numeric code.

>> I'm afraid I don't have any useful advice for the OP except that he has
>> not provided enough data. If he is really getting just a stack dump,
>> without an error message, then fiddling with iostat= isn't likely to
>> change anything. The possibilities are too numerous to list; that's not
>> much different from "the program didn't work correctly". If he did
>> actually get an error message, then he sure needs to tel us what it was.

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



Fri, 28 Nov 2008 22:47:00 GMT  
 Stackdump issues

Quote:


> > list in : end of file
> > apparent state: unit 50 named fort.50
> > last format :list io
> > lately reading direct formatted external IO
> > 0

> > It would appear that the source of problem is the confused EOF character.
> > (Is there anything specific on this issue?).

> > Also reference to formatted external IO is puzzling as this did not present
> > any previous obstacle.

> The message appears to say this file was being read with ACCESS='DIRECT'
>   which would account for problems with endfile detection.
> Interchangeability of direct and sequential access is probably not a
> portable assumption.

Yes. I'm slightly confused by a few things here, but at least we now
have some data to work with. (A lot more data than an iostat= error code
would have told us, I might add).

Note, by the way, that the message isn't saying that there is anything
wrong with doing formatted I/O. That line begining with "lately" is just
telling you some status information about what is going on. It doesn't
say that formatted I/O is a problem - just that you happened to be doing
formatted I/O "lately" (i.e. recently) on the file.

Also note that there is no concept of an "EOF character" in Fortran. I'm
not sure what you are suggesting there.

One puzzling part, as Tim notes, is the reference to direct access and
end-of-file. In the standard, those two concepts don't go together,
although some compilers allow them to. Also, list-directed I/O on a
direct access file is at least slightly unusual. In fact, I find it odd
to have formatted direct access at all, though I have seen it. So I
guess my first question is whether you are actually doing direct access,
intentionally or not? I'm not sure whether you are intentionally doing
direct access, accidentally doing so, or whether the compiler's message
is just misleading on that matter. Other matters...

I note that the file name appears to be fort.50, which suggests to me
that you might not be using an OPEN statement for the file. I must admit
that is slightly odd, though, as you can't do direct access without an
OPEN. It is certainly possible to use an OPEN and have a file name like
that, so this might be a misdirection on my part, but it does catch my
eye. The general question is whether you do have an OPEN statement and
what it looks like?

Speaking of file names, is there a chance that you just got the file
name wrong in any of several ways? If you try to read from the wrong
file (such as one that doesn't exist), you are likely to get an
end-of-file condition or some kind of error.

Finally, I note the combination of list-directed I/O and end-of-file. It
is easy to accidentally hit and end-of-file condition with list-directed
I/O because list-directed reads will read multiple records (lines) if
they don't find the number of expected fields on the first line.

That's about as much as I can usefully comment without seeing source
code.

--
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain



Fri, 28 Nov 2008 23:08:13 GMT  
 Stackdump issues
Gentlemen
Many  many thanks for your kind responses.
My source file has the following statements which did on previous occasions
funtion quite smoothly.
These are

OPEN(UNIT=50,FILE='LOSS.DAT', STATUS='OLD')
OPEN(UNIT=60, FILE='LOSS.OUT', STATUS='UNKNOWN')
OPEN(UNIT=70,FILE='LOSS.GRF', STATUS='UNKNOWN')

The source file compiles seemlessly under GNU f77 . However when the
executable is run, LOSS.OUT does not receive any output, whilst LOSS.GRF now
prints :

inaccesible number : incomprehensible list input
apparent state: uniot 50 named loss.dat
.....(etc.) as before

I might also add that all above files are created under using emacs.
I hope these throw more useful light unto this problem.

Once again many thans for any input.

Having several times tried to run the executable



Quote:


>> > list in : end of file
>> > apparent state: unit 50 named fort.50
>> > last format :list io
>> > lately reading direct formatted external IO
>> > 0

>> > It would appear that the source of problem is the confused EOF
>> > character.
>> > (Is there anything specific on this issue?).

>> > Also reference to formatted external IO is puzzling as this did not
>> > present
>> > any previous obstacle.

>> The message appears to say this file was being read with ACCESS='DIRECT'
>>   which would account for problems with endfile detection.
>> Interchangeability of direct and sequential access is probably not a
>> portable assumption.

> Yes. I'm slightly confused by a few things here, but at least we now
> have some data to work with. (A lot more data than an iostat= error code
> would have told us, I might add).

> Note, by the way, that the message isn't saying that there is anything
> wrong with doing formatted I/O. That line begining with "lately" is just
> telling you some status information about what is going on. It doesn't
> say that formatted I/O is a problem - just that you happened to be doing
> formatted I/O "lately" (i.e. recently) on the file.

> Also note that there is no concept of an "EOF character" in Fortran. I'm
> not sure what you are suggesting there.

> One puzzling part, as Tim notes, is the reference to direct access and
> end-of-file. In the standard, those two concepts don't go together,
> although some compilers allow them to. Also, list-directed I/O on a
> direct access file is at least slightly unusual. In fact, I find it odd
> to have formatted direct access at all, though I have seen it. So I
> guess my first question is whether you are actually doing direct access,
> intentionally or not? I'm not sure whether you are intentionally doing
> direct access, accidentally doing so, or whether the compiler's message
> is just misleading on that matter. Other matters...

> I note that the file name appears to be fort.50, which suggests to me
> that you might not be using an OPEN statement for the file. I must admit
> that is slightly odd, though, as you can't do direct access without an
> OPEN. It is certainly possible to use an OPEN and have a file name like
> that, so this might be a misdirection on my part, but it does catch my
> eye. The general question is whether you do have an OPEN statement and
> what it looks like?

> Speaking of file names, is there a chance that you just got the file
> name wrong in any of several ways? If you try to read from the wrong
> file (such as one that doesn't exist), you are likely to get an
> end-of-file condition or some kind of error.

> Finally, I note the combination of list-directed I/O and end-of-file. It
> is easy to accidentally hit and end-of-file condition with list-directed
> I/O because list-directed reads will read multiple records (lines) if
> they don't find the number of expected fields on the first line.

> That's about as much as I can usefully comment without seeing source
> code.

> --
> Richard Maine                     | Good judgment comes from experience;
> email: my first.last at org.domain| experience comes from bad judgment.
> org: nasa, domain: gov            |       -- Mark Twain



Sat, 29 Nov 2008 22:08:26 GMT  
 Stackdump issues

Quote:

> My source file has the following statements which did on previous occasions
> funtion quite smoothly.

> OPEN(UNIT=50,FILE='LOSS.DAT', STATUS='OLD')
> OPEN(UNIT=60, FILE='LOSS.OUT', STATUS='UNKNOWN')
> OPEN(UNIT=70,FILE='LOSS.GRF', STATUS='UNKNOWN')

> The source file compiles seemlessly under GNU f77 . However when the
> executable is run, LOSS.OUT does not receive any output, whilst LOSS.GRF now
> prints :

> inaccesible number : incomprehensible list input
> apparent state: uniot 50 named loss.dat
> .....(etc.) as before

More puzzlements.

This is a different message than reported before. I'm also puzzzled as
to how the message ended up in loss.grf unless something unshown
associates standard error with loss.grf or unit 70.

I think we are going to get nowhere without a complete copy of the
program and its data files. (Oh, and also how you compiled and invoked
the program; I ask that part because of my puzzzlement about why error
messages are ending up in loss.grf). We are just seeing isolated pieces
of information, with critical parts missing. I can't continue to ask for
pieces of data one step at a time; that way will take months. Yes, the
needed information does include the data files. At first glance, this
suggests that there is something wrong with the data in the file. Just
saying that it was prepared with emacs doesn't tell anything about what
the content is, since you can type anything into emacs. I would need to
see *BOTH* the program and the data file in order to see what the
program was trying to read, and associate that with what is on the data
file.

This kind of message suggests something like trying to read a number,
but finding non-numeric data on the file at that point. Or other similar
possibilities.

--
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain



Sat, 29 Nov 2008 23:34:51 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Stackdump under Cygwin

2. DEC Ada task stackdump possible after crash?

3. CFP: The AI Pride Issue (IEEE intelligent systems special issue)

4. How does one interpret a RUBY.EXE.stackdump file? (fwd)

5. How does one interpret a RUBY.EXE.stackdump file?

6. Smalltalk article in the current InformationWeek issue.

7. Squeak News Dec-Jan, Feb and future issues, and season's greetings

8. SqueakNews e-zine August issue is out

9. VisualWorks Call For Issues [GUI]

10. Some issues

11. Compatibility issues

12. Issues porting app from D4 to D5

 

 
Powered by phpBB® Forum Software