| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 416.1 | | TLE::EKLUND | Always smiling on the inside! | Tue Nov 07 1995 13:24 | 13 |
| 416.2 | | TLE::EKLUND | Always smiling on the inside! | Wed Nov 08 1995 11:13 | 21 |
| 416.3 | I assume you meant SYSTEM not SIGNAL, right Dave? | SUBPAC::FARICELLI | | Wed Nov 08 1995 12:50 | 0 |
| 416.4 | | TLE::EKLUND | Always smiling on the inside! | Wed Nov 08 1995 13:25 | 4 |
| 416.5 | | RHETT::LOH | | Thu Nov 09 1995 16:16 | 4 |
| 416.6 | are system(3f) returns as per errno.h? | MSBCS::SCHNEIDER | Say it with ASCII | Wed May 14 1997 19:36 | 19 |
| I'll tuck this here where it's at least SOMEWHAT related, but I don't
think it's Fortran-related at all. Mostly want to make sure I'm not
missing anything about how FORRTL handles system(3f) return values.
I've got a couple of programs, including a trivial one, that call
system(3f) and get a return of 11. Can anybody tell me what 11 is
likely to mean? It's EDEADLK, according to errno.h, but that's not
listed as a possible return from system(3) or fork(2), and I can't
think what to make of it.
The contexts where this gives trouble are kind of amusing. The trouble
occurs on only one of the systems in my shop (not on other quite
similar systems), and it only occurs if the program is linked
-non_shared. If neither of those conditions is true, the system(3f)
call behaves as expected: launches a shell w/command, and returns 0.
Thanks for any insight!
Chuck
|
| 416.7 | Did you declare system() as returning an integer? | SUBPAC::FARICELLI | | Thu May 15 1997 09:45 | 5 |
|
Just checking: did you declare system() as returning an integer?
(the default Fortran rules would have it return a real)
-- John Faricelli
|
| 416.8 | integer it is | MSBCS::SCHNEIDER | Say it with ASCII | Thu May 15 1997 12:26 | 16 |
| Yep. Here's the trivial program. In the "good" circumstances, the
output is the output from date, and the system(3f) return of 0. In the
"bad" circumstances, the output is only the system(3f) return of 11.
program system3f
integer system
external system
type *, system( 'date' )
end
Ooh, cool! I just (re)discovered that if I unlimit coredumpsize (which
I normally keep at 0), the "bad" system(3f) return changes to 139, and
a core file gets dumped by sh. 139 doesn't appear in errno.h, so that
again makes me wonder how these returns are to be interpreted.
Chuck
|
| 416.9 | Looks like shell had a segmentation violation | SUBPAC::FARICELLI | | Fri May 16 1997 14:45 | 25 |
|
Well, system(3) says that you should interpret the return status
as in wait(2). The wait(2) man page says to use the macros in sys/wait.h
to interpret the return status.
A small C code I wrote seems to indicate that the process terminated
due to a signal not caught, and the signal was 11 (segv).
#include <stdio.h>
#include <sys/wait.h>
main()
{
int status = 139;
printf("Process called exit? = %d\n", WIFEXITED(status));
printf("exit status = %d\n", WEXITSTATUS(status));
printf("Process signalled? = %d\n", WIFSIGNALED(status));
printf("signal was = %d\n", WTERMSIG(status));
}
uogsrv-77> a.out
Process called exit? = 0
exit status = -1
Process signalled? = 1
signal was = 11
|