Asan reports leak when using g_slist_append. Hard to believe, but

Platform
1

Address sanitizer is trying to tell me that I am leaking memory on this line:

G_LOCK(drop_list);
to_drop = g_slist_append(to_drop, release);
G_UNLOCK(drop_list);

And this is what I get from ASAN:

Direct leak of 144 byte(s) in 9 object(s) allocated from:
#0 0x7f42d06defdf in __interceptor_malloc …/…/…/…/src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7f42cfabacd1 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62cd1) (BuildId: 200be351efe83301ebaffb390ac30b652a88bac1)
#2 0x7f42cfad3c07 in g_slist_append (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7bc07) (BuildId: 200be351efe83301ebaffb390ac30b652a88bac1)
#3 0x559cf7fb9d3b in render_front_porch_th SRC/callback.c:406

Line 406 is the line: to_drop = g_slist_append(…

I thought it was pretty much a copy of how the manual says one should use this. However, I am looking for a problem that could originate from this line. I just don’t understand how.

2

Are you forgetting to free to_drop with g_slist_free() or g_slist_free_full()?

3

Maybe I don’t understand what exactly ASAN tells me, but how I interpret “direct leak” is that I no longer have a reference to a piece of memory that I have allocated. Later in my code, I do exactly that

g_slist_free_full (to_drop, my_free);

and as long my GSlist* is good, I should not have a leak. The fact that this happens at some later point in time in another thread, as much as I understand, should not matter.

I do struggle with the interpretation of “data is owned by the called function”, which is what the doc says about the return value g_slist_append(). I really cannot fathom what that actually means but since my mistakes are usually confined to the stuff I don’t understand, I start with looking for answers there.

4

Is there any place in your code where you modify to_drop but forget to reassign it to itself?

i.e. is there anywhere you do:

g_slist_append (to_drop, release);

by mistake, rather than:

to_drop = g_slist_append (to_drop, release);

?

5

No. There is only one g_slist_append and one g_slist_free in there for that particular GSlist.

6

Are you using G_SLICE=always-malloc G_DEBUG=gc-friendly?

7

I am not explicitly using that environment variable but I believe that on Linux, G_SLICE=always-malloc is the default. I have not yet tried gc-friendly. Will have to look that up.

I can share a conclusion on this. The problem was in fact related to that line but not in a way related to g_slist_append. Actually, a list was created because my data structures had what was equivalent to a ->next in them. They were just freed in the wrong way and (I guess) ASAN pointed out that I had allocated data on that line that I no longer can free free that data.

Still, I would really love to see one of the gurus explain what “data is owned by the called function” means in the context of g_slist_append.

8

It means that the ownership of the value returned to you isn’t transferred from the function to you. It comes from the fact that the function has no annotation, and the default for boxed types is “none”.

The annotation usually works best with actual types, as opposed to opaque, untyped containers list GList and GSList.

You’re passing the head of the list, and you’re getting back the head of the list; since you’re not prepending, the head of the list is the same. In theory, we could annotate the list argument as “transfer full”, and the return value as “transfer none”.

9

Wow. This was way above my head. I will have to think about this for a while.
Seems to be quite semantic. Anyway, I thank you for the explanation and the link.
This will help me eventually.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.