inevity / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

while(!dlclose(lib)) hungs when using tcmalloc_debug #602

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. dlclose never returns error when linking with tcmalloc_debug

What is the expected output? What do you see instead?

dlclose returns with error as the module is unloaded

What version of the product are you using? On what operating system?

gperftools 2.1

Please provide any additional information below.

Simple program:

#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
        void *lib = NULL;
        int a = 0;

        int *b = malloc(100);
        b[0]=1;

        if (!(lib = dlopen(argv[1], RTLD_LAZY| RTLD_LOCAL)))
        {
                printf("%s %s\n", dlerror(), argv[1]);
                exit (1);
        }

        while(!(a = dlclose(lib)));

        printf("ret = %d\n", a);

        free(b);
        return 0;
}

compile: gcc -g -o a a.c -ldl -ltcmalloc_debug

libfile: 
#include <stdio.h>
#include <stdlib.h>

void foo(void)
{
    int *a = NULL;
     printf("Hello, I'm a shared library");

   a = malloc(100);
   a[0] = 1;
   free (a);
}

compile: gcc -g -Wall -Werror -fPIC -shared -o libfoo.so lib.c

usage : ./a ./libfoo.so

dlclose returns allways 0 and programs hangs

linking with tcmalloc works fine. 

Original issue reported on code.google.com by florin.p...@gmail.com on 22 Jan 2014 at 2:48

GoogleCodeExporter commented 9 years ago
compiled on x86_64

Original comment by florin.p...@gmail.com on 22 Jan 2014 at 3:08

GoogleCodeExporter commented 9 years ago
while(!dlclose(lib)) doesn't look like good idea anyways.

I don't think standard promises you anything if you try to dlclose already 
closed library.

Original comment by alkondratenko on 22 Jan 2014 at 7:57

GoogleCodeExporter commented 9 years ago
I agree with you. The behavior is undefined, but it works well without 
tcmalloc_debug (with tcmalloc or default glibc). while(!dlclose(lib)) it can be 
useful in some unloading scenarios. 

Using tcmalloc_debug doesn't work even if it seems that the module become 
unloaded after the first dlclose (so there are no references from 
tcmalloc_debug to the dynamic library). 

Original comment by florin.p...@gmail.com on 22 Jan 2014 at 9:09

GoogleCodeExporter commented 9 years ago
Perhaps I misunderstand your point. But I see no reason at all why somebody 
would do dlclose in an a while loop. You should expect this to crash.

Therefore I conclude that tcmalloc not hanging or crashing is a mere luck. And 
therefore lack of this lack with tcmalloc_debug is not a bug.

Original comment by alkondratenko on 22 Jan 2014 at 10:31

GoogleCodeExporter commented 9 years ago
Agree, but I have some inherited code which I cannot modify (bad architecture). 

Can you explain if there is some direct interaction between tcmalloc_debug and 
dlclose ?

Original comment by florin.p...@gmail.com on 23 Jan 2014 at 11:15

GoogleCodeExporter commented 9 years ago
No. tcmalloc_debug does not directly interact with dlclose.

I think what likely happens is lib points to dynamically allocated memory. And 
last dlclose free-s that memory. Which in case of tcmalloc_debug fills freed 
memory with with "garbage". Exactly to make use-after-free problems like that 
more visible.

Closing as not a bug. I suggest you to find a way to fix your code.

Original comment by alkondratenko on 24 Jan 2014 at 4:25