YAAP: debugging glibc (was: huge memory usage)

Now I figured it out. And it brought my to the limits of gdb's
abstraction. The explicit dynamic loader invocations inside the glibc
build and check process are not particularly friendly to debugging, so
it's maybe the best to load the shared objects with the suspected bug
by LD_PRELOAD. Finally the huge memory allocation turned out to be for
stack allocation and have its value from getrlimit. The sanity check
inside the NPTL initialization did not discover the limitlessness on
that box.

Now that I solved the problem, I wonder where people normally set
their rlimits.

.