Re: Some question about linker dlopen with valgrind

>>            On the Android OS,  there is a question about the linker program with vaglrind memcheck.

Which version of Android?

>>
>>            The 1^st  experiment,  the libc module *do*call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind *can  not*trace malloc leak;
>>
>>            The second experiment, the libc module *do not*call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind *can*  trace malloc leak;
>>
>>            I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.

According to
    https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html
the order of execution is:
   1. linker resolves and fetches all DT_NEEDED modules (shared libraries),
      and performs all relocations for the entire process image
   2. linker calls DT_PREINIT_ARRAY functions of the main program, in order
      (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT)
   3. in dependency order (topological bottom-up) of all loaded modules (main program
      and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in order)
      for the module
   4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main program

It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT function
calls dlopen, particularly if the newly-loaded module depends on any other modules,
whether or not those modules have been loaded already.  (The dependent module
might not be initialized yet.)