ables@hi3.aca.mcc.com.UUCP (King Ables) (05/31/88)
We recently converted a sun server to run YP (like the
rest of the ones in our department) and I was asked to
fix ksh so that ~username would work again (since there
is no significant passwd file on the clients of that
server anymore). As they were the only ones with ksh,
we hadn't had this problem elsewhere before.
I thought to myself "no big deal... probably just a
recompile so the getpwnam() call works with YP."
WRONG. Of course, ksh opens the passwd file and reads
it. OK. Big deal, I yank that code and I put in a
call to getpwnam() instead... seemed real simple. But
ever since then I've been getting segmentation faults
down in the bowels of the YP code. I've grabbed a bunch
of the YP code from our sources and included it so I could
run dbx, and things are fine a LONG way down into it but
a call to malloc() dies eventually. I actually have things
working to the extent that the first call to getpwnam() works
now but it takes a llloooonnnnngggg time to do it and then
a successive call bombs. I know my call is ok because I wrote
a short program to run by itself and it works just fine. If
I load it with the .o files from ksh, things bomb again!
Ksh seems to have its own malloc(), free(), and _filbuf()
which I have renamed everywhere within ksh, but the problem
hasn't gone away. I was thinking a duplicate entry point
would explain the problem, but I think I've elminiated them.
I now thin something somewhere is overwriting something.
I don't know what version of ksh we have and I will be
contacting our AT&T sales rep to find out whether we are
entitled to a N/C upgrade or we have to buy the newest
version. I know what we have isn't the LATEST, but on the
other hand, it's perfectly acceptable to the people here and
if it involves more money, I don't know if we'll want to go
for the new version. And this should be a do-able mod, anyway!
Even if we get a new version that does this, I'm real curious
why things are getting so confused here.
Has anybody "fixed" ksh anywhere to do this? I can't believe
it can be *THAT* difficult... I must be missing something somewhere
or there must be one or two hard-to-find extra things you have
to do to it to make it work with getpwnam().... any hints?
I'm working on a Sun-3 running SunOS 3.5.
Any previous experience and/or advice anyone would like to
empart would be greatly appreciated.
-king
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ablesmeissner@xyzzy.UUCP (Michael Meissner) (06/03/88)
In article <300@hi3.aca.mcc.com.UUCP> ables@hi3.aca.mcc.com.UUCP (King Ables) writes: (summary of converting ksh to use getpwnam deleted) | Ksh seems to have its own malloc(), free(), and _filbuf() | which I have renamed everywhere within ksh, but the problem | hasn't gone away. I was thinking a duplicate entry point | would explain the problem, but I think I've elminiated them. | I now thin something somewhere is overwriting something. At Data General, we discovered that the internals of the YP stuff depend on either malloc(0) returning a useable pointer, or that NULL is an acceptable user address. In a similar note, I wish that programs would stop replacing internals of the library, or at least make it an option to use the default routines. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
dupuy@douglass.columbia.edu (Alexander Dupuy) (06/04/88)
In article <300@hi3.aca.mcc.com.UUCP> King Ables writes: We recently converted >a sun server to run YP (like the rest of the ones in our department) and I was >asked to fix ksh so that ~username would work again (since there is no >significant passwd file on the clients of that server anymore). >I thought to myself "no big deal... probably just a recompile so the >getpwnam() call works with YP." WRONG. Of course, ksh opens the passwd file >and reads it. OK. Big deal, I yank that code and I put in a call to >getpwnam() instead... seemed real simple. But ever since then I've been >getting segmentation faults down in the bowels of the YP code. >Has anybody "fixed" ksh anywhere to do this? I can't believe it can be *THAT* >difficult... Here's the fix: (credit to Chris Maio for finally tracking this down - why he has to wait until we started running YP on his workstation I don't know :-) First rip out the crap in shlib/tilde.c and make it use getpwnam() instead. (It sounds like you have already done this). Then, patch sh/io.c (your line numbers will vary). *** old/io.c Wed Nov 18 11:17:03 1987 --- io.c Sat Dec 5 18:19:57 1987 *************** *** 606,611 **** --- 610,622 ---- if ((iop->_flag&_IOREAD) == 0) return(EOF); + + #if BUGFIX + /* will this let us call getpwnam? */ + if (iop->_base == 0) + _findbuf(iop); + #endif BUGFIX + if(fnobuff(iop)) { /* unbuffered reads needed for pipes */ This patch is for ksh-i, but it ought to work for the older ksh as well. @alex -- inet: dupuy@columbia.edu uucp: ...!rutgers!columbia!dupuy
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (06/04/88)
In article <3870001@hpcuhb.HP.COM> kluft@hpcuhb.HP.COM (Ian Kluft) writes: ... >I've seen malloc() bomb many times on an AT&T 3B5 at CSU Chico when people >used char [] and char * interchangeably across function calls. These have >been considered equivalent in all the C texts way back to K&R but, in reality, >at least AT&T's C compiler cannot always swallow it. These are not equivalent in every possible context, please give an example. Also, what version of C are you running (use the command what /bin/cc). >Why it affects malloc() we never exactly figured out. But this has always >fixed problems that sounded identical to what you just described. There is a similar bug in old 3B5 compilers. It would accept null dimensions on all of the dimensions of a multidimensional array. e.g., f(a) int a[][]; of course the program crashed and burned. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
gwyn@brl-smoke.UUCP (06/05/88)
In article <894@xyzzy.UUCP> meissner@xyzzy.UUCP (Michael Meissner) writes: >In a similar note, I wish that programs would stop replacing >internals of the library, or at least make it an option to >use the default routines. Hear, hear! At the very least, they should let the C library operate the way it was designed, and use different names for the application's special versions of things like malloc(). UNIX C library malloc() implementations that I have seen are careful to allow other uses of the heap space, so a separate allocator can do its thing without interfering with malloc() (and vice-versa).
gwyn@brl-smoke.UUCP (06/05/88)
nKeywords: In article <3870001@hpcuhb.HP.COM> kluft@hpcuhb.HP.COM (Ian Kluft) writes: >I've seen malloc() bomb many times on an AT&T 3B5 at CSU Chico when people >used char [] and char * interchangeably across function calls. These have >been considered equivalent in all the C texts way back to K&R but, in reality, >at least AT&T's C compiler cannot always swallow it. Wait a doggone minute. An array has NEVER been equivalent to a pointer. The NAME of an array, when used in an expression, is (in MOST cases, but not all) converted to a pointer to its initial member. A FORMAL PARAMETER in a function definition written as char foo[] is taken to be char *foo. I have never seen an AT&T C compiler have trouble with this, and I've seen a lot of AT&T C compilers. >Why it affects malloc() we never exactly figured out. But this has always >fixed problems that sounded identical to what you just described. If someone passed the address of a statically-allocated array to free(), it could certainly cause a later malloc() to run amok.
gwyn@brl-smoke.UUCP (06/05/88)
In article <15064@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
-There is a similar bug in old 3B5 compilers. It would accept null
-dimensions on all of the dimensions of a multidimensional array. e.g.,
- f(a)
- int a[][];
-of course the program crashed and burned.
Of course the compiler "bug" was that it failed to diagnose this
incorrect C construct, not that the generated code was "wrong".rbj@icst-cmr.arpa (Root Boy Jim) (06/08/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> In article <3870001@hpcuhb.HP.COM> kluft@hpcuhb.HP.COM (Ian Kluft) writes: >I've seen malloc() bomb many times on an AT&T 3B5 at CSU Chico when people >used char [] and char * interchangeably across function calls. These have >been considered equivalent in all the C texts way back to K&R but, in reality, >at least AT&T's C compiler cannot always swallow it. Wait a doggone minute. An array has NEVER been equivalent to a pointer. The NAME of an array, when used in an expression, is (in MOST cases, but not all) converted to a pointer to its initial member. Really. Given char *foo; and char bar[] = "something";, foo is a *variable* while bar is a *constant*. Take two chapters of K&R and don't call me in the morning. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
det@hawkmoon.MN.ORG (Derek E. Terveer) (07/06/88)
In article <15064@tut.cis.ohio-state.edu>, lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: > Also, what version of C are you running (use the command what /bin/cc). Hmmm, this produces the nice but not very informative message on my machine: $ what /bin/cc /bin/cc: cc Final Release Do you know of any other way to extract the make and model of the c compiler one is using? Ps. my machine is a Acer-1100 running V/386 3.0-L2.2 -- Derek Terveer det@hawkmoon.MN.ORG uunet!rosevax!elric!hawkmoon!det