Home > Archive > Fortran > May 2004 > Re: Illegal instruction (core dumped)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Illegal instruction (core dumped)
|
|
| Gerry Thomas 2004-05-12, 9:09 pm |
|
"Ali" <hgolshani@hotmail.com> wrote in message news:s31uzaap7yv1@legacy...
> Hello, Anyone who know what is "Illegal instruction (core dumped)" ??
> When I compiled and Run a fortran files in UNIX, this error comes out.
It's a common problem in Unix, Windows, etc., and is most often caused by
programmer error, usually by exceeding the bounds of an array via an
invalid access. I've cross posted to comp.lang.fortran, a more appropriate
ng for Fortran-specific problems.
--
E&OE
HTH,
Gerry T.
| |
| James Van Buskirk 2004-05-12, 9:09 pm |
| "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
news:RoZnc.9842$dr1.375825@news20.bellglobal.com...
> "Ali" <hgolshani@hotmail.com> wrote in message news:s31uzaap7yv1@legacy...
[color=darkred]
> It's a common problem in Unix, Windows, etc., and is most often caused by
> programmer error, usually by exceeding the bounds of an array via an
> invalid access. I've cross posted to comp.lang.fortran, a more appropriate
> ng for Fortran-specific problems.
It means that a machine-level instruction mnemonic was issued
that didn't correspond to any machine-level mnemonic known to
the current processor. One way this could happen is that code
was compiled for a different processor than it was actually
run on, but most frequently some instructions would be placed
in the executable prolog that would result in a more user-
friendly diagnostic in this case.
More commonly an instruction was issued to the processor that
wasn't part of the compiled code either by:
1) overwriting the compiled code by writing to an invalid array
index (although in many environments this would be trapped
and you would get a segmentation fault or a bus error rather
than surviving to issue an invalid instruction)
2) jumping to an unanticipated address by either
2a) associating a data actual argument with a procedure dummy
argument or
2b) messing up the stack (kind of requires a compiler that
has a callee cleans up the stack calling convention, in
which case invoking a procedure with the wrong number of
arguments or the wrong number of character arguments
could do the trick.)
I would start off by trying to catch out of bounds array
accesses with a compiler switch. If fixing these little
nightmares doesn't make your problems go away, I would
then try to pin down as near as possible where the error
happens by inserting some write statements. Does it happen
right at some procedure call or return? Compare actual
arguments with dummy arguments for the offending procedure.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
|
| James Van Buskirk (aka Bruce) was almost, but not quite, entirely unlike tea:
> "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
> news:RoZnc.9842$dr1.375825@news20.bellglobal.com...
>
....[color=darkred]
> More commonly an instruction was issued to the processor that
> wasn't part of the compiled code either by:
> 1) overwriting the compiled code by writing to an invalid array
> index (although in many environments this would be trapped
> and you would get a segmentation fault or a bus error rather
> than surviving to issue an invalid instruction)
> 2) jumping to an unanticipated address by either
> 2a) associating a data actual argument with a procedure dummy
> argument or
> 2b) messing up the stack (kind of requires a compiler that
> has a callee cleans up the stack calling convention, in
> which case invoking a procedure with the wrong number of
> arguments or the wrong number of character arguments
> could do the trick.)
Or more simply, and more likely in a lot of situations (assuming all
the run-time checks are turned on so one wouldn't get out of bounds
errors in the first place): Did you optimise your code for one
particular sub-family of CPUs, such as a P4, and are running it on a
lower class machine?
On ifc, turn off the (eg) -xW swtich, and try again.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Yesterday, after years of trying, I finally managed to take a photo of a
subway train that said "INSTRUCTION CAR" just so that someday I can caption
it "...but where's the DATA CDR?" when I'm ready to make a joke that's
nerdy even by the standards of jokes about LISP. -- James "Kibo" Perry
| |
|
| "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
news:RoZnc.9842$dr1.375825@news20.bellglobal.com...
>
> "Ali" <hgolshani@hotmail.com> wrote in message news:s31uzaap7yv1@legacy...
>
> It's a common problem in Unix, Windows, etc., and is most often caused by
> programmer error, usually by exceeding the bounds of an array via an
> invalid access. I've cross posted to comp.lang.fortran, a more appropriate
> ng for Fortran-specific problems.
>
Other causes of such a symptoms with Fortran code include;
a) Calling a function or subroutine with less arguments than
the actual function or subroutine accepts --- particularly
if the argument in question gets modified.
b) Passing an argument of wrong type, particularly a type of
different physical type. For example, passing an integer
when the called subprogram expects a double precision
or a string.
Such things are not specific to Fortran. Such programming errors cause
similar errors in several programming languages (C, Pascal, etc).
| |
|
| Rob (aka Bruce) was almost, but not quite, entirely unlike tea:
> "Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
> news:RoZnc.9842$dr1.375825@news20.bellglobal.com...
....[color=darkred]
> Other causes of such a symptoms with Fortran code include;
>
> a) Calling a function or subroutine with less arguments than
> the actual function or subroutine accepts --- particularly
> if the argument in question gets modified.
>
> b) Passing an argument of wrong type, particularly a type of
> different physical type. For example, passing an integer
> when the called subprogram expects a double precision
> or a string.
These are for core dumps, but the OP was talking about "illegal
instruction" in particular - SIGILL.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Disclaimer: Due to feline interference, this post may contain typographical
errors.
| |
| Dave Seaman 2004-05-12, 9:09 pm |
| On Tue, 11 May 2004 14:24:19 GMT, TimC wrote:
> Rob (aka Bruce) was almost, but not quite, entirely unlike tea:
> ...
[color=darkred]
> These are for core dumps, but the OP was talking about "illegal
> instruction" in particular - SIGILL.
All of those things can cause an illegal instruction, in addition to various
other errors. It's a symptom of "running out of program and attempting to
execute your data".
Of course, you can also get an illegal instruction in other ways, such as
using the wrong target mode when compiling.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| glen herrmannsfeldt 2004-05-12, 9:09 pm |
| James Van Buskirk wrote:
(snip regarding "Illegal instruction (core dumped)")
> It means that a machine-level instruction mnemonic was issued
> that didn't correspond to any machine-level mnemonic known to
> the current processor. One way this could happen is that code
> was compiled for a different processor than it was actually
> run on, but most frequently some instructions would be placed
> in the executable prolog that would result in a more user-
> friendly diagnostic in this case.
> More commonly an instruction was issued to the processor that
> wasn't part of the compiled code either by:
> 1) overwriting the compiled code by writing to an invalid array
> index (although in many environments this would be trapped
> and you would get a segmentation fault or a bus error rather
> than surviving to issue an invalid instruction)
While this is possible on many machines, I don't believe that
I have ever known it to actually cause this problem.
> 2) jumping to an unanticipated address by either
> 2a) associating a data actual argument with a procedure dummy
> argument or
This one I used to know as very common for beginning Fortran
programmers. It is somehow not obvious that arrays need to be
DIMENSIONed in both main and called subroutines. The effect of
forgetting the DIMENSION in a subroutine is that the compiler
assumes is is being passed a function address, and that array
references are actually function references. If no assignments
to such an array exist, the program can easily compile without
any compile time errors.
> 2b) messing up the stack (kind of requires a compiler that
> has a callee cleans up the stack calling convention, in
> which case invoking a procedure with the wrong number of
> arguments or the wrong number of character arguments
> could do the trick.)
Another reason I don't like the callee clean up convention.
(snip)
-- glen
|
|
|
|
|