Re: vi and glibc 2.12: Assertion `_rtld_global_ro._dl_pagesize != 0

[Mike Frysinger <vapier at gentoo dot org>]

On Mon, Aug 16, 2010 at 10:58 AM, Mike Frysinger wrote:
> On Mon, Aug 16, 2010 at 9:55 AM, Allan McRae wrote:
>> On 16/08/10 08:31, Mike Frysinger wrote:
>>> 2010/5/22 PaweÅ Sikora :
>>>> afaics the getpagesize() behaves differently for static and shared libc
>>>> parts used in the testcase. here's extended example:
>>>
>>> and now that ive upgraded Gentoo to glibc-2.12.1, we're hitting this.
>>> i dont suppose you found the problem and/or a fix before i look into
>>> it ?
>>
>> I also have a bug report about this for Arch Linux. ÂStarting nscd seems to
>> "fix" the issue if that is any help...
>
> it might help in narrowing things down, but i dont consider that a
> solution as nscd is not the default and/or terribly common in Gentoo
> afaict. Âi'll work on the issue then, thanks.

the crux of the matter seems to be the fact that static apps with
glibc will dynamically load nss shared libraries when necessary.  the
static code will initialize GLRO(dl_pagesize) just fine from the
kernel auxv, but this being the static code paths, GLRO(dl_pagesize)
expands into _dl_pagesize.  when the nss shared libraries are loaded
up, the ldso is also mapped in, but it doesnt process the kernel auxv
(_dl_sysdep_start() is not called).  so the shared library
GLRO(dl_pagesize) expands into _rtld_global_ro._dl_pagesize and that
field stays at 0.

then when the nss shared libs process the request and gets to the
standard "passwd" database, it calls the shared lib versions of
malloc/stdio which rely on the __getpagesize() function.  but this
being in the shared library, it reads the shared GLRO(dl_pagesize)
which is 0, and the assert() is triggered.

i think running nscd makes things work because its nss module that
talks to the nscd daemon doesnt call any routines that implicitly rely
on __getpagesize().

i'm certainly not familiar with glibc's ldso implementation due to
it's crazy large & complicated code base, but i imagine this could be
resolved best by having the ldso declare an initializer that calls the
same functions as the ldso does when bootstrapping a normal
application (_dl_sysdep_start/etc...).  this is because the nss libs
are dlopened like any other ELF, and it tails into libc.so which tails
into the ldso.  there is no special code that i can see that goes
"this is the ldso, do xxx specially" which makes perfect sense.  only
outstanding issue there would be whether the ldso will process its own
initializers when bootstrapping a standard application.

we could back out the assert in __getpagesize(), but that would only
"fix" things until the next time someone adds code which relies on
initialized GLRO() state.

then again, any of these solutions are likely to get a response of "go
away" from drepper, so i guess this is a patch we'd have to submit to
eglibc or just carry in distros.  bottom line: static apps that use
dlopen on shared libs which pull in glibc's C library will likely
fail.  and that includes most things that rely on nss functionality.
-mike