This is the mail archive of the
mailing list for the glibc project.
Constructor used in dlopen crashes due to unitialized PLT entries.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Niels Möller <nisse at lysator dot liu dot se>
- Cc: Carlos O'Donell <carlos at systemhalted dot org>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>, Mark H Weaver <mhw at netris dot org>
- Date: Thu, 2 Jul 2015 02:09:52 +0200
- Subject: Constructor used in dlopen crashes due to unitialized PLT entries.
- Authentication-results: sourceware.org; auth=none
- References: <nn8ubcb42u dot fsf at armitage dot lysator dot liu dot se> <CAE2sS1i_-9FTFOHCEYgjoXMri7-kKcvN4R1x4DyyRWXohVZt+g at mail dot gmail dot com> <nn4mm0ashi dot fsf at armitage dot lysator dot liu dot se> <nnzj3rap7u dot fsf at armitage dot lysator dot liu dot se>
On Mon, Jun 22, 2015 at 02:43:01PM +0200, Niels Möller wrote:
> email@example.com (Niels Möller) writes:
> > I'll try to reproduce. Or maybe Mark can tell you how to reproduce it?
> Now I have reproduced the problem. I'm running on a x86_64 debian
> gnu/linux system. Not the most recent glibc, it seems I have libc-2.19
> (the debian package libc6:amd64, version 2.19-13, built from the
> "eglibc" fork). But I think Mark used the real glibc-2.21.
> Build nettle-3.1 using ./configure --enable-fat && make && make check.
> Then run the test program
> $ cat dlopen-test.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <dlfcn.h>
> int main (int argc, char *argv)
> void *handle;
> handle = dlopen (argv, RTLD_NOW);
> if (!handle)
> fprintf (stderr, "%s\n", dlerror ());
> exit (EXIT_FAILURE);
> dlclose (handle);
> exit (EXIT_SUCCESS);
> $ ./dlopen-test ~/build/nettle-fat/libnettle.so
> Segmentation fault
> In gdb, it gets as far as
> Dump of assembler code for function _nettle_cpuid@plt:
> => 0x00007ffff7601b90 <+0>: jmpq *0x22c842(%rip) # 0x7ffff782e3d8
> 0x00007ffff7601b96 <+6>: pushq $0x26
> 0x00007ffff7601b9b <+11>: jmpq 0x7ffff7601920
> But the address in that slot is not yet properly relocated,
> (gdb) x/gx 0x7ffff782e3d8
> 0x7ffff782e3d8: 0x0000000000009b96
So problem isn't in ifunc but in constructor. My first suggestion would
be use constructor but you already did that so I was puzzled. Now as
crash is just in constructor without any ifunc call we know that there
is something fishy there.