segmentation fault (SIGSEGV)
Benjamin
After compiling the whole codes without no errors, I'm getting into
the trouble of "segmentation fault" when I try to run the executable
file.
It's a little bit annoying....
Although I've known it's generated by several factors:
# An array index is outside the declared range.
# The name of an array index is misspelled.
# The calling routine has a REAL argument, which the called routine
has as INTEGER.
# An array index is miscalculated.
# The calling routine has fewer arguments than required.
# A pointer is used before it has been defined.
....I can't find the fatal factor(s).
But is there any software or package to check this progress?
My OS is openSUSE 11.0, the compiler is SCons.
steve
Scons appears to be some sort of integrated build environment.
What is the actual Fortran compiler installed on your system?
--
steve
Benjamin
Oh, sry, gFortran is the actual comiler
Alois Steindl
a debugger might be a great help in this situation.
If you are planning to dig deep into programming,
learning to use the available debuggers is a worthwhile option.
Another possible reason: Too small memory sizes, like stack size.
Can usually be corrected with ulimit.
Good luck
Alois
mecej4
1. Compile with the checking options of your compiler set ON
(e.g., -C -traceback ... check your compiler options list see what to use)
AND/OR
2. Compile with -g, and use tools such as GDB and VALGRIND.
Once you establish that the seg-fault is traceable to your code, you may see
it as a good thing, if the alternative is to propagate erroneous results
throughout your program with no notification to you.
Compiling without errors merely establishes that those errors that are
detectable by static analysis of the code have been removed. By no means
does it follow that there are no more errors left in the code.
-- mecej4
Benjamin
Thanks a lot.
I've complied the program with SCons...
now I'm trying to debug the program with gdb..
steve
With gfortran try the compiler options '-fbounds-check -Wall -Wextra -
g'.
The -Wall and -Wextra option will most likely produce a large amount
that (IMHO) should be fixed. -fbounds-check should help catch array
index issues.
--
steve
dpb
...
> Thanks a lot.
> I've complied the program with SCons...
> now I'm trying to debug the program with gdb..
As others have noted, use all available error trapping and traceback
options first.
One could also disable optimization until the problem(s) is/are resolved
as well as it may make determination of just where something went sought
somewhat easier.
Rarely would there be no clues or breadcrumbs to follow after such has
been done...
--
Louis Krupp
>
> After compiling the whole codes without no errors, I'm getting into
> the trouble of "segmentation fault" when I try to run the executable
> file.
> It's a little bit annoying....
> Although I've known it's generated by several factors:
<snip>
> # The name of an array index is misspelled.
Use "implicit none" if you're not doing so already. You'll have to
declare all of your variables, and unless you declare two variables with
very similar names, the compiler is likely to catch misspellings.
> # The calling routine has a REAL argument, which the called routine
> has as INTEGER.
<snip>
> # The calling routine has fewer arguments than required.
<snip>
Use modules. The compiler will convert arguments as necessary (someone
want to verify this?) or flag argument list mismatches.
Louis
Ron Shepard
Louis Krupp <lkrupp...@indra.com.invalid> wrote:
>
> Use modules. The compiler will convert arguments as necessary
No, nothing is converted.
> (someone
> want to verify this?)
You must be thinking of some other language. Other languages do
sometimes do silent conversions to match arguments.
> or flag argument list mismatches.
This part *IS* right, and that's one of the reasons why modules are so
useful.
$.02 -Ron Shepard
Louis Krupp
> In article<5KWdnQAwhvwt9ZjR...@indra.net>,
> Louis Krupp<lkrupp...@indra.com.invalid> wrote:
>
>>
>> Use modules. The compiler will convert arguments as necessary
>
> No, nothing is converted.
>
>> (someone
>> want to verify this?)
>
> You must be thinking of some other language. Other languages do
> sometimes do silent conversions to match arguments.
So reals aren't truncated to integers?
Louis
dpb
> On 6/1/2010 9:40 PM, Ron Shepard wrote:
>> You must be thinking of some other language. Other languages do
>> sometimes do silent conversions to match arguments.
>
> So reals aren't truncated to integers?
In argument lists? No, a REAL in a CALL statement for a routine
expecting an INTEGER will generate a mismatched argument type error (in
the module during compilation) and a mismatched call if forced to link
outside of one where a compiler may not be able to tell of the mismatch.
--
mecej4
To add to what dpb said: If the expected INTEGER is used as a subscript but
a real (or another mismatched type) was passed instead, a prompt SEGFAULT
may be expected.
-- mecej4
Louis Krupp
Likely (given the format of IEEE floating point, for example), but not
necessarily (if a high virtual address plus garbage with high-order bits
turned on wrap around to a low, valid virtual address).
The same thing would happen in that Other Language with which I'm more
familiar.
Louis
Ron Shepard
Louis Krupp <lkrupp...@indra.com.invalid> wrote:
> > You must be thinking of some other language. Other languages do
> > sometimes do silent conversions to match arguments.
>
> So reals aren't truncated to integers?
No. Actually I can't think of any situation offhand where reals are
truncated to integers. In some contexts, such as mixed arithmetic,
integers are silently converged to reals, but I can't think of any
situations where the reverse occurs. And especially for subprogram
arguments, no conversion is ever done silently, not even between
different kinds of the same type, much less between different types.
$.02 -Ron Shepard
glen herrmannsfeldt
(snip, someone wrote)
>> So reals aren't truncated to integers?
> No. Actually I can't think of any situation offhand where reals are
> truncated to integers. In some contexts, such as mixed arithmetic,
> integers are silently converged to reals, but I can't think of any
> situations where the reverse occurs. And especially for subprogram
> arguments, no conversion is ever done silently, not even between
> different kinds of the same type, much less between different types.
Well, reals are truncated on assignment to an integer variable,
but maybe you don't count that.
Some systems allow real expressions for subscripts, truncating
the value to an integer.
Or course the intrinsic functions specifically designed to
convert non-integer values to integers, as appropriate.
But yes, it is not done for subroutine arguments.
-- glen
steve
> Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
>
> (snip, someone wrote)
>
> >> So reals aren't truncated to integers?
> > No. Actually I can't think of any situation offhand where reals are
> > truncated to integers. In some contexts, such as mixed arithmetic,
> > integers are silently converged to reals, but I can't think of any
> > situations where the reverse occurs. And especially for subprogram
> > arguments, no conversion is ever done silently, not even between
> > different kinds of the same type, much less between different types.
>
> Well, reals are truncated on assignment to an integer variable,
> but maybe you don't count that.
>
> Some systems allow real expressions for subscripts, truncating
> the value to an integer.
>
program ohmy
real x(3)
x = (/ 1, 2, 3 /)
print *, x(2.1)
end
troutmask:sgk[219] gfc4x -o z k.f
k.f:4.17:
print *,
x(2.1)
1
Warning: Extension: REAL array index at (1)
troutmask:sgk[220] ./z
2.0000000
--
steve
Craig Powers
Certainly not with non-VALUE arguments, but that's true of just about
any language I might care to mention; it just becomes obvious with C,
C++, etc. because they use value arguments so frequently.
Although I don't think there's a strong technical reason for it, it does
not appear that Fortran will do any automatic conversion for numeric
VALUE arguments. It seems like something that could be put in without
an obnoxious amount of effort considering that the text of the '03
standard already says, "If the VALUE attribute is specified, the effect
is as if the actual argument is assigned to a temporary, and the
temporary is then argument associated with the dummy argument." (But
that's in a Note, and the normative text requires that the actual
argument be type-compatible with non-pointer, non-allocatable dummy with
no qualifications.)
Richard Maine
> Although I don't think there's a strong technical reason for it, it does
> not appear that Fortran will do any automatic conversion for numeric
> VALUE arguments. It seems like something that could be put in without
> an obnoxious amount of effort...
other than completely blowing generics out of the water. :-(
And maybe a few other things, but that one immediately occurs to me.
Plus, of course, being completely unlike any other procedure arguments
in the language, which would be bound to cause no end of confusion. It
sure seems a lot simpler and more consistent to just be able to say that
arguments must match and there is never any conversion instead of having
to add "well, except in this one special class of cases, where it is
different just because it could be."
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Richard Maine
> Craig Powers <craig....@invalid.invalid> wrote:
>
> > Although I don't think there's a strong technical reason for it, it does
> > not appear that Fortran will do any automatic conversion for numeric
> > VALUE arguments. It seems like something that could be put in without
> > an obnoxious amount of effort...
>
> other than completely blowing generics out of the water. :-(
>
> And maybe a few other things, but that one immediately occurs to me.
A related one that occurred to me right after posting that is all the
stuff about how procedure resolution works. Admitedly, that is related
in that generics get all tied up with it. But I'd call it an additional
complication because it would still need work even if one came up with
some rule to make it compatible with generics. In fact, any such rule
would have to be stuck right in the middle of the the procedure name
resolution stuff.
That's one of the messier few pages of the standard. The only reason it
doesn't generate zillions of questions here is that almost all of the
cases in real programs are dead trivial; when you call a procedure by
name, there is usually only one accessible procedure with that name and
that's the one you get. Anything that touches those particular messy
pages counts as a pretty obnoxious amount of effort in my book.
glen herrmannsfeldt
(snip)
> Certainly not with non-VALUE arguments, but that's true of just about
> any language I might care to mention; it just becomes obvious with C,
> C++, etc. because they use value arguments so frequently.
PL/I will do it under the appropriate conditions, generating
a temporary and passing that. The value won't be written back
to the original variable, so you have to be careful.
> Although I don't think there's a strong technical reason for it, it does
> not appear that Fortran will do any automatic conversion for numeric
> VALUE arguments.
It makes some sense for BIND(C) VALUE arguments, as C would
do it with a prototype in scope.
> It seems like something that could be put in without
> an obnoxious amount of effort considering that the text of the '03
> standard already says, "If the VALUE attribute is specified, the effect
> is as if the actual argument is assigned to a temporary, and the
> temporary is then argument associated with the dummy argument." (But
> that's in a Note, and the normative text requires that the actual
> argument be type-compatible with non-pointer, non-allocatable dummy with
> no qualifications.)
-- glen
Richard Maine
> Craig Powers <craig....@invalid.invalid> wrote:
>
> > Although I don't think there's a strong technical reason for it, it does
> > not appear that Fortran will do any automatic conversion for numeric
> > VALUE arguments.
>
> It makes some sense for BIND(C) VALUE arguments, as C would
> do it with a prototype in scope.
As noted in other threads, Fortran isn't C. And no, I don't buy the
"this was just for comparison purposes." Sure reads like an explicit
suggestion to put in into Fortran to me.
"C does it" isn't much of a reason to argue that something should be
done in Fortran. It actually has to fit in the Fortran language. Yes,
that is so even for BIND(C) procedures. C does lots of things in
function calls that Fortran doesn't do.
Earlier today or yesterday you were suggesting that something be more
consistent. Now you want to make BIND(C) VALUE arguments behave
fundamentally different from all other arguments, including other
BIND(C) and other VALUE arguments; one has to have both to trigger the
special case? This for no reason other than that C does it? You appear
to have a different notion of consistency than I do.
Do note, by the way, that just because a procedure is BIND(C), that
doesn't mean it is necessarily a procedure written in C.
But I don't know why I bother to post this. It ain't going to happen. No
way. As noted in my other post, it would invalidate existing standard
conforming codes by badly breaking generics. Yes, I'd bet there are
existing codes that use BIND(C) procedures in generics. It is a natural
thing to do. While incompatibilities like that have been known to
happen, they tend to fall into one of 2 classes.
1. The incompatibility was not noticed until after the new standard was
published. Often that isn't even enough, as there have been known to be
errata to fix that kind of problem. Such an unnoticed incompatibility
has more than once been cited as being an adequate reason for an errata.
But this one isn't unnoticed. It wouldn't be unnoticed even if I hadn't
pointed out. It is a glaring big incompatibility.
or
2. There is darn good justification given. Nothing here has been even
close to the kind of justification that tends to be needed. If you think
otherwise, well.... lots of luck. I'll be confident inmy claim that it
ain't gonna happen.
Craig Powers
> Craig Powers <craig....@invalid.invalid> wrote:
>
>> Although I don't think there's a strong technical reason for it, it does
>> not appear that Fortran will do any automatic conversion for numeric
>> VALUE arguments. It seems like something that could be put in without
>> an obnoxious amount of effort...
>
> other than completely blowing generics out of the water. :-(
>
> And maybe a few other things, but that one immediately occurs to me.
Oops, yeah, I forgot about that.
C++ manages it, but from what I recall when I followed C++ more closely,
conversion and overload matching rules are a consistent sore point.
There are definitely dragons there, so it would make sense to stay away
with Fortran.