Heap Check doesn't work for Python on Fedora 18

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a simple Python script

% cat hello.py 
print "hello"

2. Run the following command

% HEAPCHECK=minimal LD_PRELOAD=/usr/lib64/libtcmalloc.so /usr/bin/python 
hello.py
WARNING: Perftools heap leak checker is active -- Performance may suffer
hello
Check failed: !do_main_heap_check: should have done it
Aborted (core dumped)

3.

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

On Fedora 14 I see

% HEAPCHECK=minimal LD_PRELOAD=/usr/lib64/libtcmalloc.so /usr/bin/python 
/tmp/hello.py
WARNING: Perftools heap leak checker is active -- Performance may suffer
hello
Have memory regions w/o callers: might report false leaks
No leaks found for check "_main_" (but no 100% guarantee that there aren't 
any): found 3475 reachable heap objects of 1999541 bytes

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

2.0-7. Fedora 18.

Please provide any additional information below.

Original issue reported on code.google.com by wei....@gmail.com on 23 Feb 2013 at 12:25

• Merged into: #437

[GoogleCodeExporter]

I think the version is just 2.0. The number 7 is a Fedora revision number.

It looks like the problem isn't related to Python after all. Even an empty C 
program can cause this problem.

Original comment by wei....@gmail.com on 23 Feb 2013 at 12:40

[GoogleCodeExporter]

Can this be related to Issue 376? The problem seems to also happen when the 
program exits.

Original comment by wei....@gmail.com on 23 Feb 2013 at 12:41

[GoogleCodeExporter]

Did you test with trunk revision? I couldn't see this issue in my x86_64 
environment:

$ HEAPCHECK=minimal LD_PRELOAD=.libs/libtcmalloc.so python hello.py 
WARNING: Perftools heap leak checker is active -- Performance may suffer
hello
No leaks found for check "_main_" (but no 100% guarantee that there aren't 
any): found 485 reachable heap objects of 1541748 bytes

Original comment by zatr...@gmail.com on 23 Feb 2013 at 2:20

[GoogleCodeExporter]

Thanks for your response. I can confirm that the head version doesn't have this 
problem.

Original comment by wei....@gmail.com on 24 Feb 2013 at 7:39

[GoogleCodeExporter]

Appears to have been related to the glibc changes introduced last year that 
caused the ordering of functions/destructors called by atexit to change.

Original comment by chapp...@gmail.com on 10 Mar 2013 at 8:38

• Changed state: Duplicate