A 32-bit process _can't_* be bigger than 4GB, and as far as the kernel
is concerned, AFAIK won't be bigger than 2GB in terms of regular memory
(although it could have a frame buffer or something mapped in the
part of the address space reserved for I/O devices, making its total
size perhaps appear larger than 2GB, but still definitely <= 4GB).
*actually, a 32-bit _address space_ can't be. On suitable hardware, a 32-bit
kernel
can use special instructions to address more than 4GB of RAM, and some other
OSs allow even a user process to own more than one address space. I don't think
any of that applies here though.
Assuming you're running OpenSolaris and not Solaris 10 or SXCE,
ksh is actually ksh93, and was built both 32-bit and 64-bit.
Programs like that are typically just a link to (or copy of)
/usr/lib/isaexec, which looks in subdirectories (i86 or amd64 for x86,
sparcv7 or sparcv9 for SPARC) of the $PATH directories to find a
64-bit or 32-bit version, and then execs the 64-bit version if on a 64-bit
capable system, otherwise the 32-bit version.
Example:
$ uname -a
SunOS virtualbox-indiana 5.11 snv_108 i86pc i386 i86pc
$ pargs -x $$|grep AT_SUN_EXECNAME
AT_SUN_EXECNAME 0xfffffd7fffdfffdb /usr/bin/amd64/ksh93
$ pflags $$
789: ksh
data model = _LP64 flags = ORPHAN|MSACCT|MSFORK
/1: flags = ASLEEP waitid(0x7,0x0,0xfffffd7fffdfebf0,0xf)
$ file /usr/bin/ksh* /usr/bin/*/ksh*
/usr/bin/ksh: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically
linked, not stripped
/usr/bin/ksh93: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically
linked, not stripped, no debugging information available
/usr/bin/amd64/ksh93: ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR
FPU], dynamically linked, not stripped, no debugging information available
/usr/bin/i86/ksh93: ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available
(My /usr/bin/ksh and /usr/bin/ksh93 are not quite the same, possibly due to
having
separately put a ksh93 update on the system. But /usr/bin/ksh is till tiny,
just a
wrapper, and even if I specifically execute /usr/bin/ksh, what ends up running
is still /usr/bin/amd64/ksh93. So don't let that confuse the issue.)
To get around the problem
pmap: cannot examine 5608: address space is changing
and get a closer look, try stopping the process first:
pstop 5608
and then running pmap or whatever to inspect it, and finally running
prun 5608
to let it run again.
I suspect the shell script being run is the real problem; not too many
well-written shell scripts should grow to such monster size.
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
