On Mon, Aug 29, 2005 at 05:07:54PM -0700, /dev/null wrote:
> > > > umem_flags/X
> > > libumem.so.1`umem_flags:
> > > libumem.so.1`umem_flags: 0
> >
> > It looks like the environment variables were set up
> > after umem was initialized;
> > is you application doing:
> >
> > putenv("UMEM_DEBUG=default");
> >
> > or something? That isn't going to work, since the
> > putenv() call will
> > do an allocation, which will initialize umem. You
> > need to set the
> > environment variables up before the process is
> > invoked.
> >
> > Cheers,
> > - jonathan
> >
>
> I know for sure that the code is not doing (btw this is not my code)
>
> putenv("UMEM_DEBUG=default");
>
> because our developers are not even aware of UMEM_DEBUG.
The plot thickens.
> Do you believe that the code is doing something funky with putenv()
> calls? I will have to browse thru the code to see all the putenv()
> calls. Should I be looking for anything else?
What's the output of ::umem_status in mdb? What does:
% truss -ae -t exec -u ::umem_setup_envvars -u ::getenv /path/to/my/program
output? (I'm looking for UMEM_DEBUG in the envp: output, as well as a section
like:
/1 at 1: -> libumem:umem_setup_envvars(0x0, 0x0, 0xff2f3040, 0xff3a2000)
/1 at 1: -> libc:getenv(0xff3775b0, 0x0, 0x0, 0x0)
/1 at 1: <- libc:getenv() = 0
/1 at 1: -> libc:getenv(0xff3775d0, 0x1, 0xa7cc8, 0x0)
/1 at 1: <- libc:getenv() = 0
/1 at 1: -> libc:getenv(0xff3775f4, 0x1, 0xa7cc8, 0x0)
/1 at 1: <- libc:getenv() = 0
/1 at 1: <- libumem:umem_setup_envvars() = 0xff38b000
Cheers,
- jonathan
--
Jonathan Adams, Solaris Kernel Development
