Bug 22345 - Free does not seem to free the chunk or does not mark it as free.
Summary: Free does not seem to free the chunk or does not mark it as free.
Status: CLOSED INVALID
Alias: None
Product: glibc
Classification: Unclassified
Component: malloc (show other bugs)
Version: 2.26
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-24 10:43 UTC by ghozt
Modified: 2017-10-25 08:02 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Running same program using different libc (606 bytes, text/plain)
2017-10-24 10:43 UTC, ghozt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ghozt 2017-10-24 10:43:11 UTC
Created attachment 10554 [details]
Running same program using different libc

Free does not seem to free the chunk or does not mark it as free.

See attachment, i use version 2.26 on archlinux x86_64.I also tried with an ubuntu libc 2.26, same result.


I don't know if it's a bug or a feature ..
Comment 1 Carlos O'Donell 2017-10-24 14:20:09 UTC
(In reply to ghozt from comment #0)
> Created attachment 10554 [details]
> Running same program using different libc
> 
> Free does not seem to free the chunk or does not mark it as free.
> 
> See attachment, i use version 2.26 on archlinux x86_64.I also tried with an
> ubuntu libc 2.26, same result.
> 
> 
> I don't know if it's a bug or a feature ..

How are you deciding that the chunk is not free?

Please see this document for the relevant details:
https://sourceware.org/glibc/wiki/MallocInternals

If that answers your questions, please mark this bug closed.
Comment 2 François Boisson 2017-10-24 19:21:33 UTC
Well, in fact, there is a 

free(c) in the programm.

But if we make a malloc of the same size, the chunk is allocate. So effectively, it is free.

But last bit of the previous size still remains at 1.

So it's not a bug of glibc, but

either I did not read the good doc of glibc
or the doc is not uptime.

Thonks to have read.

I think this can be closed.

PS: I know my english is bad.
Comment 3 dj@redhat.com 2017-10-24 20:06:32 UTC
If you are using the latest glibc, you have the per-thread cache enabled.  Chunks stored in the cache are still "in use" as far as the malloc internals are concerned (i.e. they won't participate in consolidations).  To see what I mean, set GLIBC_TUNABLES=glibc.malloc.tcache_count=0 in your environment to disable the cache.
Comment 4 François Boisson 2017-10-24 20:40:01 UTC
Really thinks :)
It's a great beginning of explain what happens.
F.B
Comment 5 ghozt 2017-10-25 04:26:28 UTC
(In reply to dj@redhat.com from comment #3)
> If you are using the latest glibc, you have the per-thread cache enabled. 
> Chunks stored in the cache are still "in use" as far as the malloc internals
> are concerned (i.e. they won't participate in consolidations).  To see what
> I mean, set GLIBC_TUNABLES=glibc.malloc.tcache_count=0 in your environment
> to disable the cache.

Makes sense, thanks for your answer :)

I close the issue.

Regards, 

ghozt