Shibboleth Developers

["Scott Cantor" <>]

> I know I've visited this subject numerous times but this time I've
> gathered some data. I let the shibd daemon run for a week under
> valgrind's Massif and this is the results:

I'm afraid I don't know what any of that tells me. 1.3 is not where the
testing effort should be spent. This is even more true if you're telling me
that there's an RPC problem. That code is gone in 2.0, so this is not
relevant.
 
> From what I can see 99% of the growing memory usage I see in Linux
> comes from SharChild::svc_create().

I have a hard time believing that, it's just a wrapper around a couple of
Sun RPC calls to wrap the sockets. Perhaps the problem is too much socket
creation, which is going to be much worse with a prefork Apache. Has anybody
produced these results with an Apache that isn't creating so many processes?

If I really thought that the problem was socket growth, I'd say bounding it
is necessary, but I haven't seen any sign of that being the case.

Is it also possible that it's misreporting this? Every worker thread will
call that function, so maybe it's just making a bad association.
 
> I've poked around but I didn't  
> have enough time to reach any conclusion... Maybe someone who knows  
> the code can shed some light into the problem so we can finally fix  
> this issue?

I don't believe it can be fixed without replacing the glibc heap code. It
simply doesn't release the memory back to the OS. That's probably a big
reason why people prefer processes to threads, it compensates for that
behavior.

All this code works fine on Windows (within reason, it certainly doesn't
grow the heap size like this). That tells me it's the OS or a library issue,
not something in this code we can "fix".

There are other heap libraries available, some that are supposed to be
dynamically loadable in place of the standard one. That would probably be
the only fix.

I guess another difference is that I'm using an embedded copy of the ONC
library on most other platforms. Perhaps the Linux version is broken in some
way. I don't think Solaris shows behavior that's very different though. It
spikes and doesn't release the RAM. But it reuses the RAM it has, which is
the difference between a bad heap manager and a leak.

-- Scott