barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (06/01/91)
Here's one for the gurus in the audience. ULTRIX Software
Support is currently stumped.
Any program compiled and run on our DECsystem 5400 dumps core
if it calls getpwuid() (or other getpw???() function). However, the SAME
BINARY runs fine on a DECstation 3100.
If we compile the program on a DECstation 3100, it runs fine on
either the DS3100 oir the DS5400.
Now the weird part: both the DS5400 and the DS3100 are physically
using the SAME COMPILER and SAME LIBRARIES. (The 3100 mounts them by NFS.)
OS == Ultrix 4.0, rev 179.
Here is a minimal example. Yes, it still dumps core if I add
the usual #include lines.
$ cat foo.c
main()
{
getpwuid(getuid());
}
$ cc -g foo.c
$ a.out
Segmentation fault (core dumped)
$ dbx a.out core
dbx version 2.0
Type 'help' for help.
Corefile produced from file "a.out"
Child died at pc 0x10016140 of signal : Segmentation fault
reading symbolic information ...
[using memory image in core]
(dbx) where
> 0 ntohl.ntohl(0x0, 0x0, 0x0, 0x0, 0x0) [0x1001613c]
(dbx)
The only lead I have is that the 5400 is acting as Hesiod server
for the 3100. /etc/svc.conf looks fine: passwd is "local" on the 5400
and "local,bind" on the 3100. Security level is plain old BSD.
ULTRIX software support has been "unable to reproduce" the problem.
Of course, they haven't actually tried it on the same setup, which might
be why.... <mild sarcasm and mild sigh>
Dan
//////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett, Department of Computer Science Johns Hopkins University |
| INTERNET: barrett@cs.jhu.edu | |
| COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP |
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////grr@cbmvax.commodore.com (George Robbins) (06/02/91)
In article <8523@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > > Here's one for the gurus in the audience. ULTRIX Software > Support is currently stumped. > > Any program compiled and run on our DECsystem 5400 dumps core > if it calls getpwuid() (or other getpw???() function). However, the SAME > BINARY runs fine on a DECstation 3100. > If we compile the program on a DECstation 3100, it runs fine on > either the DS3100 oir the DS5400. Well, have you compared the object files? Seems like it could be some kind of unitialized variable thing or maybe both systems don't see the same object file... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
diamond@jit533.swstokyo.dec.com (Norman Diamond) (06/04/91)
In article <8523@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > Any program compiled and run on our DECsystem 5400 dumps core >if it calls getpwuid() (or other getpw???() function). However, the SAME >BINARY runs fine on a DECstation 3100. > If we compile the program on a DECstation 3100, it runs fine on >either the DS3100 oir the DS5400. > Now the weird part: both the DS5400 and the DS3100 are physically >using the SAME COMPILER and SAME LIBRARIES. (The 3100 mounts them by NFS.) But perhaps grabbing different portions of the libraries. Is your environment set up the same way on both machines (BSD vs. POSIX vs. XOPEN vs. SYSTEM_V, etc.)? Also, considering the number of symbolic links in the pathnames for the compiler and libraries, it is worth checking again to see if both machines are really getting the same ones. (Sorry, I'm not allowed to do any kernel work or other things that might help answer your problem, but the matter of identical binaries raises slightly different questions.) -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Permission is granted to feel this signature, but not to look at it.