how to find segmentation fault problem with Sun f90 
Author Message
 how to find segmentation fault problem with Sun f90

I suspect this isn't exactly the best group for this question,
but I figured there were some of you fortran programmers out
there who work on Sun systems with Sun's f90. I'm trying to
debug a program that runs for about 6 hours then crashes with
a segmentation fault, and no other information. I have
compiled it and run it with options -C -g -fnonstd, but still
I get no additional information about what is causing this
segmentation fault. Are there any compiler options or any
other easy way to figure out where the problem is occuring.
The fact that it takes about 6 hours to get to this point
makes this a difficult problem to diagnose by print statements,
for example. Thanks for any help in advance.

Randy



Wed, 31 Aug 2005 00:00:03 GMT  
 how to find segmentation fault problem with Sun f90

Quote:

> I suspect this isn't exactly the best group for this question,
> but I figured there were some of you fortran programmers out
> there who work on Sun systems with Sun's f90. I'm trying to
> debug a program that runs for about 6 hours then crashes with
> a segmentation fault, and no other information. I have
> compiled it and run it with options -C -g -fnonstd, but still
> I get no additional information about what is causing this
> segmentation fault. Are there any compiler options or any
> other easy way to figure out where the problem is occuring.
> The fact that it takes about 6 hours to get to this point
> makes this a difficult problem to diagnose by print statements,
> for example. Thanks for any help in advance.

Do your compiler options include array bounds checking?

Do you get a core file?

Louis



Wed, 31 Aug 2005 00:52:59 GMT  
 how to find segmentation fault problem with Sun f90

Quote:

> I suspect this isn't exactly the best group for this question,
> but I figured there were some of you fortran programmers out
> there who work on Sun systems with Sun's f90. I'm trying to
> debug a program that runs for about 6 hours then crashes with
> a segmentation fault, and no other information. I have
> compiled it and run it with options -C -g -fnonstd, but still
> I get no additional information about what is causing this
> segmentation fault. Are there any compiler options or any
> other easy way to figure out where the problem is occuring.
> The fact that it takes about 6 hours to get to this point
> makes this a difficult problem to diagnose by print statements,
> for example. Thanks for any help in advance.

Did you run the executable in the de{*filter*}? (or use the de{*filter*} to read the core file
from the crash) That should provide some info (e.g. line number, routine, etc) on where it
crashed. Answering the why may be harder depending on the where.

cheers,

paulv

--
Paul van Delst

Ph: (301)763-8000 x7748
Fax:(301)763-8545



Wed, 31 Aug 2005 01:00:19 GMT  
 how to find segmentation fault problem with Sun f90

Quote:


>>I suspect this isn't exactly the best group for this question,
>>but I figured there were some of you fortran programmers out
>>there who work on Sun systems with Sun's f90. I'm trying to
>>debug a program that runs for about 6 hours then crashes with
>>a segmentation fault, and no other information. I have
>>compiled it and run it with options -C -g -fnonstd, but still
>>I get no additional information about what is causing this
>>segmentation fault. Are there any compiler options or any
>>other easy way to figure out where the problem is occuring.
>>The fact that it takes about 6 hours to get to this point
>>makes this a difficult problem to diagnose by print statements,
>>for example. Thanks for any help in advance.

> Did you run the executable in the de{*filter*}? (or use the de{*filter*} to read the core file
> from the crash) That should provide some info (e.g. line number, routine, etc) on where it
> crashed. Answering the why may be harder depending on the where.

> cheers,

> paulv

No, I didn't run the executable in the de{*filter*}, and I'm not even sure how
to do so. I understand that answering the why may be difficult, but that's
impossible until I can figure out the where, which is what I'm trying to
do.

So, are you telling me that if I just start the program in the de{*filter*} and
let it run until it bombs that it will give me the information about where
it's crashing?

Randy



Wed, 31 Aug 2005 01:20:47 GMT  
 how to find segmentation fault problem with Sun f90

Quote:


>> I suspect this isn't exactly the best group for this question,
>> but I figured there were some of you fortran programmers out
>> there who work on Sun systems with Sun's f90. I'm trying to
>> debug a program that runs for about 6 hours then crashes with
>> a segmentation fault, and no other information. I have
>> compiled it and run it with options -C -g -fnonstd, but still
>> I get no additional information about what is causing this
>> segmentation fault. Are there any compiler options or any
>> other easy way to figure out where the problem is occuring.
>> The fact that it takes about 6 hours to get to this point
>> makes this a difficult problem to diagnose by print statements,
>> for example. Thanks for any help in advance.

> Do your compiler options include array bounds checking?

> Do you get a core file?

> Louis

As I mentioned in my original post, I did use the -C option which
checks for array bounds.

A core file is dumped, but I have no idea what to do with that.

Randy



Wed, 31 Aug 2005 01:22:08 GMT  
 how to find segmentation fault problem with Sun f90

: I suspect this isn't exactly the best group for this question,
: but I figured there were some of you fortran programmers out
: there who work on Sun systems with Sun's f90. I'm trying to
: debug a program that runs for about 6 hours then crashes with
: a segmentation fault, and no other information. I have
: compiled it and run it with options -C -g -fnonstd, but still
: I get no additional information about what is causing this
: segmentation fault. Are there any compiler options or any
: other easy way to figure out where the problem is occuring.
: The fact that it takes about 6 hours to get to this point
: makes this a difficult problem to diagnose by print statements,
: for example. Thanks for any help in advance.

Have you tried running under dbx? That sometimes helps. Otherwise, I'm
afraid it probably will be debug-by-write - which isn't so painful if
output is made to a terminal (and that also ensures that buffers are
flushed).

Richard

------------------------------------------------------------------

IoA                               http://www.ast.cam.ac.uk/~rge21/
Cambridge
PGP Fingerprint: AC9C 8DB8 A8FC 443B 0C9F 06C0 518B F8F1 ECEA 82CB



Wed, 31 Aug 2005 01:26:04 GMT  
 how to find segmentation fault problem with Sun f90

Quote:


> : I suspect this isn't exactly the best group for this question,
> : but I figured there were some of you fortran programmers out
> : there who work on Sun systems with Sun's f90. I'm trying to
> : debug a program that runs for about 6 hours then crashes with
> : a segmentation fault, and no other information. I have
> : compiled it and run it with options -C -g -fnonstd, but still
> : I get no additional information about what is causing this
> : segmentation fault. Are there any compiler options or any
> : other easy way to figure out where the problem is occuring.
> : The fact that it takes about 6 hours to get to this point
> : makes this a difficult problem to diagnose by print statements,
> : for example. Thanks for any help in advance.

> Have you tried running under dbx? That sometimes helps. Otherwise, I'm
> afraid it probably will be debug-by-write - which isn't so painful if
> output is made to a terminal (and that also ensures that buffers are
> flushed).

> Richard

> ------------------------------------------------------------------

> IoA                               http://www.ast.cam.ac.uk/~rge21/
> Cambridge
> PGP Fingerprint: AC9C 8DB8 A8FC 443B 0C9F 06C0 518B F8F1 ECEA 82CB

No, I'm going to try running under dbx, which I don't know, but
hopefully can get going pretty easily. I agree that in general
it isn't painful to debug-by-write, except that in this case
it takes 6 hours to get to that point.

Thanks, Randy



Wed, 31 Aug 2005 01:30:52 GMT  
 how to find segmentation fault problem with Sun f90

Quote:

> As I mentioned in my original post, I did use the -C option which
> checks for array bounds.

> A core file is dumped, but I have no idea what to do with that.

Sorry about that -- I don't have access to a Sun and I didn't know
what -C did.

You may be able to do something like "dbx <executable> <core file>"
instead of starting another six-hour run.

The documentation for dbx should tell you where to go from there.

Louis



Wed, 31 Aug 2005 02:13:56 GMT  
 how to find segmentation fault problem with Sun f90

Quote:

> > Did you run the executable in the de{*filter*}? (or use the de{*filter*} to read the core file
> > from the crash) That should provide some info (e.g. line number, routine, etc) on where it
> > crashed. Answering the why may be harder depending on the where.

> > cheers,

> > paulv

> No, I didn't run the executable in the de{*filter*}, and I'm not even sure how
> to do so.

Reading the man pages on dbx (I think that's what it is called on a Sun system would be a
start). I'm not claiming to be a dbx guru so make sure you take anything I say with a
grain of salt :o)  For problems like seg fault errors a de{*filter*} can be invaluable.

Typically what I do when using a de{*filter*} is to have all the source code available in the
same directory (this may not be necessary, but it's a simple method). I start the de{*filter*}
loading my_program:

% dbx my_program
(dbx)

At the (dbx) prompt you can type "help all" (or something like that) to get help on
anyting dbx related, or "help <command>" to get help on the command in question, e.g.:

(dbx) help trace
<....info printed out here....>

To run your program in the de{*filter*}, simply type  "run". It will chug away for the
requisite 6 hours and then crash. At that point you should be able to view where you are
in the code. If your code has crashed somewhere in a system routine (e.g. an OS memory
routine or somesuch), you can use the "up" and "down" commands to traverse the call stack
until you reach your own code. You should also be able to view the current value of
variables (but I'm not sure - the seg fault may have cleared stuff).

Once you've determined where your code has crashed, you can set breakpoints (usually via
the "stop" command) to halt execution before the offending bit of code, rerun it and
examine variables ("print" or "duel") and/or step ("step" and "next" commands) through
each individual line of code to try and determine exactly _why_ the crash is occurring. In
your case, a 6 hour wait may not be too efficient, so you might just want to use the core
file you already have.

BTW, if you start dbx with no executable argument on the command line, I think the default
behaviour is to read the core file produced by the crash. You _should_ be able to use that
in a similar fashion as if you just ran the code through the de{*filter*} (but I'm not 100%
sure). Might save you some time if you already have the core file.

Quote:
> I understand that answering the why may be difficult, but that's
> impossible until I can figure out the where, which is what I'm trying to
> do.

Yeah, that's what I meant.

Quote:
> So, are you telling me that if I just start the program in the de{*filter*} and
> let it run until it bombs that it will give me the information about where
> it's crashing?

Yes. Hence the name "de{*filter*}" :o)  Using dbx for the first time can be a bit of a pain
(or even subsequent times if it's been a while), but I've found that perserverance pays
off - and I usually end up discovering something interesting about the system I'm working
on. If your system has a gui frontend for dbx that may make it easier (but not
always...some dbx gui's are horrendous).

cheers and good luck,

paulv

--
Paul van Delst

Ph: (301)763-8000 x7748
Fax:(301)763-8545



Wed, 31 Aug 2005 02:29:28 GMT  
 how to find segmentation fault problem with Sun f90

Quote:


>>>Did you run the executable in the de{*filter*}? (or use the de{*filter*} to read the core file
>>>from the crash) That should provide some info (e.g. line number, routine, etc) on where it
>>>crashed. Answering the why may be harder depending on the where.

>>>cheers,

>>>paulv

>>No, I didn't run the executable in the de{*filter*}, and I'm not even sure how
>>to do so.

> Reading the man pages on dbx (I think that's what it is called on a Sun system would be a
> start). I'm not claiming to be a dbx guru so make sure you take anything I say with a
> grain of salt :o)  For problems like seg fault errors a de{*filter*} can be invaluable.

> Typically what I do when using a de{*filter*} is to have all the source code available in the
> same directory (this may not be necessary, but it's a simple method). I start the de{*filter*}
> loading my_program:

> % dbx my_program
> (dbx)

> At the (dbx) prompt you can type "help all" (or something like that) to get help on
> anyting dbx related, or "help <command>" to get help on the command in question, e.g.:

> (dbx) help trace
> <....info printed out here....>

> To run your program in the de{*filter*}, simply type  "run". It will chug away for the
> requisite 6 hours and then crash. At that point you should be able to view where you are
> in the code. If your code has crashed somewhere in a system routine (e.g. an OS memory
> routine or somesuch), you can use the "up" and "down" commands to traverse the call stack
> until you reach your own code. You should also be able to view the current value of
> variables (but I'm not sure - the seg fault may have cleared stuff).

> Once you've determined where your code has crashed, you can set breakpoints (usually via
> the "stop" command) to halt execution before the offending bit of code, rerun it and
> examine variables ("print" or "duel") and/or step ("step" and "next" commands) through
> each individual line of code to try and determine exactly _why_ the crash is occurring. In
> your case, a 6 hour wait may not be too efficient, so you might just want to use the core
> file you already have.

> BTW, if you start dbx with no executable argument on the command line, I think the default
> behaviour is to read the core file produced by the crash. You _should_ be able to use that
> in a similar fashion as if you just ran the code through the de{*filter*} (but I'm not 100%
> sure). Might save you some time if you already have the core file.

>>I understand that answering the why may be difficult, but that's
>>impossible until I can figure out the where, which is what I'm trying to
>>do.

> Yeah, that's what I meant.

>>So, are you telling me that if I just start the program in the de{*filter*} and
>>let it run until it bombs that it will give me the information about where
>>it's crashing?

> Yes. Hence the name "de{*filter*}" :o)  Using dbx for the first time can be a bit of a pain
> (or even subsequent times if it's been a while), but I've found that perserverance pays
> off - and I usually end up discovering something interesting about the system I'm working
> on. If your system has a gui frontend for dbx that may make it easier (but not
> always...some dbx gui's are horrendous).

> cheers and good luck,

> paulv

Thanks to everyone for their suggestions. I will give these all a try and
report back later if I'm able to solve the problem. I've gotten spoiled
using the Lahey compiler, which seems to do a much better job at telling
you where crashes occur, and certainly their --chk option I've found to
be outstanding for tracking down bugs.

Randy



Wed, 31 Aug 2005 03:02:36 GMT  
 how to find segmentation fault problem with Sun f90

| I suspect this isn't exactly the best group for this question,
| but I figured there were some of you fortran programmers out
| there who work on Sun systems with Sun's f90. I'm trying to
| debug a program that runs for about 6 hours then crashes with
| a segmentation fault, and no other information. I have
| compiled it and run it with options -C -g -fnonstd, but still
| I get no additional information about what is causing this
| segmentation fault. Are there any compiler options or any
| other easy way to figure out where the problem is occuring.
| The fact that it takes about 6 hours to get to this point
| makes this a difficult problem to diagnose by print statements,
| for example. Thanks for any help in advance.

it has been a few years since I used a SUN machine for computations,
but to find such problems I used to compile the code with the
-g  -ftrap=common

options (enables trapping of floating point exceptions), then I start
dbx with the executable, and type

 catch fpe

then

 run

this makes the code exit at the spot with the problem.

Helge



Wed, 31 Aug 2005 03:08:46 GMT  
 how to find segmentation fault problem with Sun f90

Quote:

> I've gotten spoiled
> using the Lahey compiler, which seems to do a much better job at telling
> you where crashes occur,

A great service to Fortrankind (the people, not the language) would be done if the
standard error output from any sort of run time error was the offending line in the source
code - especially if the code was compiled with the -g debug (or equivalent) option. Some
platforms/compilers do it (yay), others don't (snuckingfessinrottenrasterdly).

cheers,

paulv

--
Paul van Delst

Ph: (301)763-8000 x7748
Fax:(301)763-8545



Wed, 31 Aug 2005 04:22:44 GMT  
 how to find segmentation fault problem with Sun f90


Quote:

> ....  Using dbx for the first time can be a bit of a pain

Since 'Sun' was mentioned, shouldn't he just use the SunPro Workshop?
May not offer much that is new, but it does have a nice interface ...
and if Makefiles are involved, it will help you move faster ..

--


                         Remove 'bounceback' for email address



Wed, 31 Aug 2005 05:36:18 GMT  
 how to find segmentation fault problem with Sun f90
After all, perhaps some more hints what to do:

- If the core file or the program run gives you an error number - such as
"seg10" - use the command "catch no." or in the mentioned case "catch
10". This helps to find the offending source code line.

- You can use the Sun Workshop which is just a front-end of dbx and makes
it for beginners much easier to deal with breakpoints, evaluation, stack
traversing etc. Perhaps it takes some more time to reach the crash, but
it will work.

- If you use SUN f90 I must agree that it has some problems finding
errors sometimes - particulary in large code - and particulary in case of
non-initialized variables (particulary double precision's). Perhaps you
should check this as well.

- Just another idea, what was the problem I had some weeks ago: we are
using a mixture of f90 and c code (c for the use of a callable
optimisation library) and the link between f90 and c can't be checked
with -C flag. So perhaps if you are using some kind of callable libraries
which return results check the bounds of the arrays and this stuff that
is exchanged between your code and the library.

- Last: totalview is in imho the better de{*filter*} and helps finding
errors, dbx doesn't find

hth

Heiko



Wed, 31 Aug 2005 18:53:03 GMT  
 how to find segmentation fault problem with Sun f90


Quote:
> I'm trying to
> debug a program that runs for about 6 hours then crashes with
> a segmentation fault

Using SunOS and Sun f77 ten years ago, the Sun fortran manual explained dbx
in simplified terms for fortran users.  Approximately what one did for
after-the-fact debugging from the core dump was to type "dbx
<name_of_executable>", then at the dbx prompt type "where", and you saw the
stack traceback to where the program crashed. It was as easy as that, though
I may have left out something minor.  It could find the error from the core
dump.

Alternatively, you could restart by typing "dbx <name_of_executable>", then
at the dbx prompt type "run", and after it crashed, at the dbx prompt type
"where".  This does not require the core dump, which your machine may or may
not be configured to do.

When I switched to g77, I wondered how to do the same thing using the gnu
de{*filter*} gdb.  After a few inquiries in this newsgroup, the answer turned
out that everything was exactly the same as on the Sun if you executed from
within gdb.  But I don't know whether the Sun software still works this way,
or whether their current fortran documentation is still written with simple
cookbook methods for the scientific fortran user who is not a programmer.
It is worth a careful look at all the documentation supplied with the
fortran compiler.



Thu, 01 Sep 2005 12:51:35 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Sun F90 segmentation fault

2. bug Ada Verdix SUN : segmentation fault at compil time

3. bug Ada Verdix SUN : segmentation fault at compil time

4. Segmentation Fault: When attempting to run Sun Fortran code on Linux

5. Segmentation Fault on SUN Ultra1,OK on HP and DEC

6. F90: segmentation fault with array intrinsics?

7. Segmentation Fault error FOUND !

8. Q:[F90][SUN] Compilation Problem with Sun Fortran 90 1.2

9. Another Segmentation Fault problem

10. Strange segmentation fault problem with C++ extension

11. Memory problem Segmentation fault / exhaust

12. segmentation fault problem

 

 
Powered by phpBB® Forum Software