Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site dalcs.UUCP Path: utzoo!utcsri!dalcs!forceten From: forceten@dalcs.UUCP (ForceTen Enterprises) Newsgroups: net.unix-wizards,net.micro.pc Subject: Re: Xenix panic (easy to do) Comment and an alternate method. Message-ID: <1535@dalcs.UUCP> Date: Tue, 16-Jul-85 15:58:52 EDT Article-I.D.: dalcs.1535 Posted: Tue Jul 16 15:58:52 1985 Date-Received: Wed, 17-Jul-85 01:57:59 EDT References: <181@medstar.UUCP> Organization: Dalhousie University, Halifax, N.S., Canada Lines: 45 ][b In article 181@medstar, Robin Cutshaw writes: > Here is a quick way to panic the IBM Xenix kernel (both original and updated). > This works for both the small and medium models. (use cc shr.c -o shr -lx). > ... Code leading up to > sdenter(share, SD_WRITE); > (void )getcwd(pnbuf,100); /* THIS IS THE KILLER LINE */ > sdleave(share); > > sdfree(share); Although the crash is tragic, I would guess that removing the cast to (void) would cause the code to work correctly. Microsoft documents this behaviour in some obscure place (does the same on both XT and AT versions of the compiler) in the Xenix manuals. A similar piece of code crashes my XT, and causes the AT to segment fault. On the AT, a simpler means of instantly halting my machine without so much as a panic (power cycle to reboot) $ cat > /dev/monochrome I use an AT w 1 Meg memory, Paradise Systems Multidisplay Card. Has anyone encountered this on a system with a standard IBM colour adaptor? ||!][b --------------------- Neil S Erskine decvax!dartvax!dalcs!force10!erskine ForceTen Enterprises Inc. 3845 Dutch Village Rd. Halifax, N.S. (902) 453-0040 -- Neil S Erskine decvax!dartvax!dalcs!force10!erskine ForceTen Enterprises Inc. 3845 Dutch Village Rd. Halifax, N.S. (902) 453-0040