Constructor used in dlopen crashes due to unitialized PLT entries.

[Ondřej Bílka]

On Mon, Jun 22, 2015 at 02:43:01PM +0200, Niels Möller wrote:
> nisse@lysator.liu.se (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[1], 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.