karl@ddsw1.MCS.COM (Karl Denninger) (04/15/91)
Some more followup on the crash problem I was experiencing with ISC 2.2 (panics in "namei"): o) The crashes occur regardless of whether the OS is 2.2, 2.2.1, 2.2 with the POSIX fix disk, 2.2.1 with the POSIX fix disk, with and without the network drivers and with and without the TCP/IP & NFS patches (SSU 4.a & 4.b) o) If one doesn't run >any< posix applications (compiled with "-Xp") then the crashes do not occur. Once you start using the Posix options (I had compiled trn with this specifically to allow multi-group support -- needed to solve an access control problem) the system will start panicing in "namei" on a frequent basis. With the kind of use I have here, that "frequent basis" means in less than 24 hours. That POSIX was responsible was verified by removing the new copy of "trn" from the system -- we've now been up for over a day without problems. The >only< change made which caused the system to once again be stable was the removal of this one application. Generic environment information: 80386/25 cache system (our own) Math chip (80387) with the u-area writable parameters set OFF Security patch is not installed (we have a '387 and don't need it) AHA1542A/1542B SCSI host adapter (both tried with identical results) tunable parameters for the adapter had no effect within operational boundaries of the motherboard Equinox Megaport /24 with 2.3.0 drivers (latest and best-working available) 3 SCSI MAXTOR disk drives and a Archive 2150S tape ATI Wonder VGA card and monitor Pretty standard stuff, actually. This has been reported to Marty Stuart at ISC. If anyone is running POSIX applications regularly and is NOT experiencing problems I'd really like to hear about it.... it would provide an interesting comparison. Actually, the better solution would be to fix it and support multiple groups internally in the system utilities. That's really the only need I have for POSIX support (although that might not be the only reason others want it :-) One problem with POSIX is that it requires filenames <= 14 characters; it returns an error on open of a filename that is too long rather than truncating it. This is a minor annoyance that requires code changes in many software packages. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Anon. arch. (nuucp) 00:00-06:00 C[SD]T, req: /u/public/sources/DIRECTORY/README
src@scuzzy.in-berlin.de (Heiko Blume) (04/17/91)
real strange, i have compiled quite a lot with something like
gcc -D_POSIX_SOURCE -DPOSIX -o bla bla.c -lcposix
for instance, bash-1.05, tcsh-5.20.02, elm-2.3#11 and lots more.
i never tried the stuff mentioned in cc(1) like setenv OSTYPE POSIX,
since it works for me without that (and my hacked bash definitely
is full of posix job control etc).
never ever have i seen a panic whatsoever. i run 2.2.1
with the security fix on a informtech 386/33 board, aha-1542a,
lotsa disks, hercules card.
however, it seems that iscntrl() in /lib/libcposix.a definitely
doesn't care about what you tell it at all in /lib/chrclass/*.
i assume there are more bugs in the posix stuff, but i haven't
discovered any really serious ones yet.
--
Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!]
public UNIX source archive [HST V.42bis]:
scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
uucp scuzzy!/src/README /your/homeeric@mks.mks.com (Eric Gisin) (04/18/91)
In article <1991Apr16.235122.26807@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes:
real strange, i have compiled quite a lot with something like
gcc -D_POSIX_SOURCE -DPOSIX -o bla bla.c -lcposix
for instance, bash-1.05, tcsh-5.20.02, elm-2.3#11 and lots more.
i never tried the stuff mentioned in cc(1) like setenv OSTYPE POSIX,
since it works for me without that (and my hacked bash definitely
is full of posix job control etc).
never ever have i seen a panic whatsoever. i run 2.2.1
with the security fix on a informtech 386/33 board, aha-1542a,
lotsa disks, hercules card.
There is a big difference between compiling with "cc -Xp" or "OSTYPE=POSIX cc",
and just linking with -lcposix. Both give you access to the extra POSIX.1
functions like job control, but the former gives you a different run-time
start-up. This start-up does a __setostype(_OS_POSIX), which changes
the behaviour of some systems calls. For example, you get supplementry group
permissions, path components longer that 14 characters give ENAMETOOLONG,
and various other things (like crashes).jim@segue.segue.com (Jim Balter) (04/20/91)
In article <1991Apr16.235122.26807@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >real strange, i have compiled quite a lot with something like > >gcc -D_POSIX_SOURCE -DPOSIX -o bla bla.c -lcposix This doesn't turn on the kernel POSIX support. cc -Xp or OSTYPE=POSIX cc or cc /lib/lcrtp.o or doing the system call that the latter does will. >i never tried the stuff mentioned in cc(1) like setenv OSTYPE POSIX, That is interpreted by cc, not gcc. It is equivalent to the -Xp flag and causes linking with /lib/crtp1.o and /lib/libcposix.a . >never ever have i seen a panic whatsoever. Because you aren't using kernel posix.
alex@am.sublink.org (Alex Martelli) (04/20/91)
src@scuzzy.in-berlin.de (Heiko Blume) writes:
:real strange, i have compiled quite a lot with something like
:
:gcc -D_POSIX_SOURCE -DPOSIX -o bla bla.c -lcposix
:
:for instance, bash-1.05, tcsh-5.20.02, elm-2.3#11 and lots more.
:i never tried the stuff mentioned in cc(1) like setenv OSTYPE POSIX,
:since it works for me without that (and my hacked bash definitely
:is full of posix job control etc).
Ah, just the man for me!-) Being reasonably familiar with BSD job
control, and having tried to gain understanding of Posix jc via the
standards text and some discussions in the comp.std.unix archives, I
find I must have failed, since when I tried to hack bash to posix jc
on my Interactive 2.2 I got no results save a few shell hangs! I bet
I'm not the only one in a similar predicament... would you like to
enlighten us? I think you can assume that BSD jc is understood,
indeed jc-related diffs on Bash with a few theory pointers might be
enough...
I'll gratefully accept 'literature pointers' too, of course.
--
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).src@scuzzy.in-berlin.de (Heiko Blume) (04/21/91)
jim@segue.segue.com (Jim Balter) writes: >In article <1991Apr16.235122.26807@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >>real strange, i have compiled quite a lot with something like >> >>gcc -D_POSIX_SOURCE -DPOSIX -o bla bla.c -lcposix >This doesn't turn on the kernel POSIX support. cc -Xp or OSTYPE=POSIX cc >or cc /lib/lcrtp.o or doing the system call that the latter does will. well, it looks like you need /lib/pcrt* if you want the posix group stuff and the different handling of filenames >14 chars. however, all the posix functions i have used until now (sig*, tioc* etc) do not require it. does anyone have a list of *all* those functions that do require it? -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
jim@segue.segue.com (Jim Balter) (04/23/91)
In article <7193@segue.segue.com> I write: >This doesn't turn on the kernel POSIX support. cc -Xp or OSTYPE=POSIX cc >or cc /lib/lcrtp.o or doing the system call that the latter does will. My editor or my fingers hiccuped. That should have been /lib/pcrt1.o
src@scuzzy.in-berlin.de (Heiko Blume) (04/24/91)
alex@am.sublink.org (Alex Martelli) writes: >src@scuzzy.in-berlin.de (I) wrote: [i say that i made bash work with posix job control] >Ah, just the man for me!-) Being reasonably familiar with BSD job >control, and having tried to gain understanding of Posix jc via the >standards text and some discussions in the comp.std.unix archives, I >find I must have failed, since when I tried to hack bash to posix jc >on my Interactive 2.2 I got no results save a few shell hangs! I bet >I'm not the only one in a similar predicament... would you like to >enlighten us? I think you can assume that BSD jc is understood, >indeed jc-related diffs on Bash with a few theory pointers might be >enough... >I'll gratefully accept 'literature pointers' too, of course. er, in fact i sort of hacked my way through it. ten zillion test programs...the only documentation i had was the isc man pages and some advise from the net, later i managed to get the standard ($100 - ugh). i have posted my diffs for bash-1.05 to alt.sources in january, you should be able to find them on some archive sites. those diffs weren't really posix compliant though, but since bash-1.07 was announced shortly after, i didn't post the better ones. unfortunately 1.07 still isn't out :-( however, here's whats needed (on ISC 2.2.1) as far as i figured out: - replace setjmp() and longjmp() with sigsetjmp() and siglongjmp(). change the variables, casts etc of type jmp_buf to sigjmp_buf. sigsetjmp() needs a second argument specifying whether the signal mask shall be preserved or not. i always used '1' - preserve mask. - replace ioctl(fd, TIOCSPGRP, &pgrp) with tcsetpgrp(fd, pgrp). - replace setpgrp(pid, pgrp) with setpgid(pid, pgrp). - replace killpg(pgrp, SIGNAL) with kill(-(pgrp), SIGNAL). - the signaling functions need some intro: they work on 'objects' in the sense of an abstract data type, and must therefore be 'created/initialized'. i.e. a int oldmask = sigblock(1 << (SIGCHOKE-1)) in BSD style job control translated to posix style jc is sigset_t oldmask, newmask; sigemptyset(&oldmask); /* must initialize */ sigemptyset(&newmask); sigaddset(&newmask, SIGCHOKE); /* add signal to set */ sigprocmask(SIG_BLOCK, &newmask, &oldmask); that looks very bloated, but it has it's advantages. especially the 32 signal limit that a (long) int imposes can be avoided. to restore the old signal mask replace the BSD sigsetmask(oldmask); with the posix call sigprocmask(SIG_SETMASK, &oldmask, (sigset_t *)0); a set of signals can be unblocked using SIG_UNBLOCK. to wait for one or more specific signals, BSD uses int mask=0; /* any will do here */ sigpause(mask); while posix suggests sigset_t nullmask; sigemptyset(&nullmask); /* any signal will do */ sigsuspend(&nullmask); that's about it, i hope i didn't make any mistakes. as usual, corrections are welcome. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
van@zeus.ocs.com (Van Gale) (04/25/91)
In an article (Heiko Blume) shows an example of posix job control: > sigset_t oldmask, newmask; > sigemptyset(&oldmask); /* must initialize */ > sigemptyset(&newmask); > sigaddset(&newmask, SIGCHOKE); /* add signal to set */ > sigprocmask(SIG_BLOCK, &newmask, &oldmask); I haven't been able to read the standard but I assumed (from looking at a sigprocmask man page) that it wasn't *really* necessary to initialize oldmask with a call to sigemptyset since sigprocmask is supposed to return the original mask there. Does the standard issue a good reason for doing this anyway? ---- Van Gale van@ocsmd.ocs.com