mark@applix.UUCP (Mark Fox) (11/13/87)
Reply-Path:
I have a program built on an Ultrix 2.0 system. It executes a new system
call (getmnt) which didn't exist in 1.2. Guess what happens if I try to execute
it on a 1.2 system -- it dumps core with the following message and stack trace:
% a.out
Bad system call (core dumped)
% adb a.out
$c
_getmnt(7fffe2e0,7fffd8dc,a00) from 30e
_getdfnms(7fffe304) from 155
_main(1,7fffe380,7fffe388) from 92
Two questions:
1) How can I *reliably* tell at runtime that I am on a pre-2.0 version of
Ultrix so that my application doesn't issue this or other "Bad system calls"?
(A compile-time check that would force me to have separate 1.2 and 2.0
distributions of my application is not acceptable. Requiring all of my
users to upgrade to 2.0 isn't either.)
2) Will subsequent versions of Ultrix simply return an error to a
"Bad system call" or will they continue to rudely and inexcusably dump
core? Really, dumping core is a bug not a feature, isn't it?
--
Mark Fox
Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300
uucp: {ames,rutgers}!harvard!m2c!applix!markchuck@felix.UUCP (11/18/87)
Reply-Path: (Re: getmnt() syscall not in Ultrix 1.2, causing core dump.) You can catch the SIGSYS signal and then try to do something else. I sure hope you don't trying to read any directories, though! Tom Truscott
chuck@felix.UUCP (11/18/87)
Reply-Path: In article <12683@felix.UUCP>, mark@applix.UUCP (Mark Fox) writes: > I have a program built on an Ultrix 2.0 system. It executes a new system call > (getmnt) which didn't exist in 1.2. Guess what happens if I try to execute it > on a 1.2 system -- it dumps core with the following message and stack trace Just like DECs VMS, you don't want to develop programs on newer versions to run on older versions. You want to do just the opposite. [Actually, with judicious use of logical names and saving of appropriate libraries from previous versions, it is fairly easy to develop and maintain versions of older applications and programs on newer versions of VMS. I know several vendors who do just this; their desire being to support one version of the application which is compatable across many versions of the operating system. Alas, even in VMS there comes a point where you want to use a NEW feature, and of course, you can't go backwards from there and still be compatable. cwv] -- \\\!/// From: Pete Schmitt _ _ UUCP: {allegra|ihnp4}!decwrl!tsc.dec.com!pete ( Q Q ) It's okay to say the U... word. ---,,,,-------U-------,,,,---
chuck@felix.UUCP (11/18/87)
Reply-Path: In article <12683@felix.UUCP> mark@applix.UUCP (Mark Fox) writes: >2) Will subsequent versions of Ultrix simply return an error to a > "Bad system call" or will they continue to rudely and inexcusably dump > core? Really, dumping core is a bug not a feature, isn't it? Ahem -- I suspect that a SIGSYS was generated, and since you didn't establish a signal handler for it, you got the default action, which is "abnormal termination with actions" (in POSIX parlance). An example of how to recover from unsupported system calls, extracted from my getdents() system call emulation for "random UNIX variants", follows; it can be adapted to deal with other cases where there is a C library system call hook but where it is not certain that the target system's kernel will support the system call: #include <signal.h> extern int _getdents(); /* actual system call */ static enum { maybe, no, yes } state = maybe; /* does _getdents() work? */ /*ARGSUSED*/ static void sig_catch( sig ) int sig; /* must be SIGSYS */ { state = no; /* attempted _getdents() faulted */ } int getdents( fildes, buf, nbyte ) /* returns # bytes read; 0 on EOF, -1 on error */ int fildes; /* directory file descriptor */ char *buf; /* where to put the (struct dirent)s */ unsigned nbyte; /* size of buf[] */ { ... switch ( state ) { void (*shdlr)(); /* entry SIGSYS handler */ register int retval; /* return from _getdents() if any */ case yes: /* _getdents() is known to work */ return _getdents( fildes, buf, nbyte ); case maybe: /* first time only */ shdlr = signal( SIGSYS, sig_catch ); retval = _getdents( fildes, buf, nbyte ); /* try it */ (void)signal( SIGSYS, shdlr ); if ( state == maybe ) /* SIGSYS did not occur */ { state = yes; /* so _getdents() must have worked */ return retval; } /* else fall through into emulation */ /* case no: /* fall through into emulation */ } ...
fuat@cunixc.columbia.edu (Fuat C. Baran) (11/18/87)
Reply-Path: In article <12683@felix.UUCP> mark@applix.UUCP (Mark Fox) writes: >1) How can I *reliably* tell at runtime that I am on a pre-2.0 version of > Ultrix so that my application doesn't issue this or other "Bad system calls"? > (A compile-time check that would force me to have separate 1.2 and 2.0 > distributions of my application is not acceptable. Requiring all of my > users to upgrade to 2.0 isn't either.) You should be able to call uname(2) and check the system type before issuing the getmnt system call. (Unless the uname(2) call is new too. I can't verify that since I don't have a pre-2.0 system around right now.) --Fuat -- ARPANET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 280-5128 New York, NY 10025
chuck@felix.UUCP (11/20/87)
Reply-Path: In article <12683@felix.UUCP> mark@applix.UUCP (Mark Fox) writes: > Two questions: > > 1) How can I *reliably* tell at runtime that I am on a pre-2.0 version of > Ultrix so that my application doesn't issue this or other "Bad system calls"? > (A compile-time check that would force me to have separate 1.2 and 2.0 > distributions of my application is not acceptable. Requiring all of my > users to upgrade to 2.0 isn't either.) It's grody, but it could be done: catch SIGSYS. That tells you (after the fact) that you just did a boo-boo. You could checkpoint with setjmp and longjmp out of your interrupt handler. For complex programs this gets tiresome, but it may work well for simple to medium strength utilities. You might also just be able to increment a flag and check it later. > 2) Will subsequent versions of Ultrix simply return an error to a > "Bad system call" or will they continue to rudely and inexcusably dump > core? Really, dumping core is a bug not a feature, isn't it? Well, it is arguable whether it is a bug or a feature. I would consider it a feature, though a useless one for most people. It did allow you to figure out which system call was bad, didn't it? As I mentioned, I think you are getting a SIGSYS and the default action for that is to dump core. You could ignore that signal ... but it doesn't solve the problem of getting the information you were hoping to get with your system call! Rick