I am posting the email message from Jonathan to the forum:
(One of these days I'll subscribe to the list)
-------------------------------------------------------------------------------------------------------------
On Tue, Aug 30, 2005 at 06:34:41AM -0700, prasad jlv wrote:
>
>
> Here's the output from ::umem_status
> -------------------------------------------------------
> > ::umem_status
> Status: ready and active
> Concurrency: 8
> Logs: (inactive)
> Message buffer:
> recursive allocation during getenv(3C) calls --
> getenv(3C) results ignored.
Well, that would definitely be the problem, then; here's the
troublesome path:
> /1 at 1: -> libumem:umem_setup_envvars(0x0, 0x0,
> 0xfece8bc0, 0xff3a2000)
> /1 at 1: -> libc:getenv(0xff37742c, 0x0, 0x0, 0x0)
> /1 at 1: <- libc:getenv() = 0xffbffb04
> /1 at 1: -> libc:getenv(0xff37744c, 0x0, 0x9fc4c,
> 0x0)
> /1 at 1: <- libc:getenv() = 0
> /1 at 1: -> libc:getenv(0xff377470, 0x1, 0x9fc4c,
> 0x0)
> /1 at 1: <- libc:getenv() = 0
**
> /1 at 1: -> libumem:umem_setup_envvars(0x1, 0x0,
> 0xfece8bc0, 0xff3a2000)
> /1 at 1: <- libumem:umem_setup_envvars() = 1
> /1 at 1: <- libumem:umem_setup_envvars() = 0xff211b40
** is where we recurse; looking at the code, we're recursing in:
if ((h = dlopen(0, RTLD_FIRST | RTLD_LAZY)) != NULL) {
there's a bug in the recursion detection code; it assumes that the
dlopen
call can't trigger '.init' sections. I'll investigate and get back to
you.
Cheers,
- jonathan
-------------------------------------------------------------------------------------------------------------
This message posted from opensolaris.org
