It seems there are several memory leakage and I described them bellow:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The first leakage is a memory leakage in the 'media_results_get' callback function. The media items generated inside 'media_lightmediascanner_scan' function with several dynamic memory allocations and this function provide media item data structure for either 'media_results_get' (media request handler) and 'on_interface_proxy_properties_changed' ( media_added event handler) callback functions. in 'on_interface_proxy_properties_changed' after producing afb response JSON, the media list data structure release properly by 'g_list_free_full(list, free_media_item)' so the 'free_media_item' function de-allocates each media item memory, but the same process doesn't apply for releasing media-list items in 'media_results_get' function and just media-list object memory is releasing with the 'g_list_free(list)' function so the child media items memory will leak !!!

It leaks a considerable amount of memory on each 'media_result' verb call. I profiled the memory with Valgrind, called the 'media_result' and logged the results two times, first with the single call then with 30 calls with a memory flash including 70 media files. On a single query, We had 4,965 bytes definite leak memory and the leak value for 30 calls was 148,950 bytes, and if you dived 148,950 to 30 you will get exactly  4965 ! It means for a 70 media file, mediascanner leaks ~5KB on each query. The amount of leaked memory can be different according to the length of media-paths and their meta-data!!

Memory leakage for the single call on 'media_results_get':

==916== 4,965 (1,204 direct, 3,761 indirect) bytes in 43 blocks are definitely lost in loss record 81 of 88
==916== at 0x4841590: calloc (vg_replace_malloc.c:752)
==916== by 0x55291E5: g_malloc0 (in /usr/lib/libglib-2.0.so.0.5800.0)

Memory leakage for 30 calls on 'media_results_get':

==1044== 148,950 (36,120 direct, 112,830 indirect) bytes in 1,290 blocks are definitely lost in loss record 87 of 90
==1044== at 0x4841590: calloc (vg_replace_malloc.c:752)
==1044== by 0x55291E5: g_malloc0 (in /usr/lib/libglib-2.0.so.0.5800.0)

 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The second leakage is 23 bytes and it happens in 'MediaPlayerManagerInit' with binding 'init' function once a binding load. The file object allocated and not released after usage.

==916== 23 (16 direct, 7 indirect) bytes in 1 blocks are definitely lost in loss record 12 of 88
==916== at 0x483E970: malloc (vg_replace_malloc.c:299)
==916== by 0x55291AB: g_malloc (in /usr/lib/libglib-2.0.so.0.5800.0)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The third leakage which is the biggest one, it is memory leakage with the sqlite3 interface. This memory leakage is not static and increases on every 'media_added' event rise & 'media_result' verb call. With a flash memory containing around 70 media files, sqltie3 binary leaks around 700KB (with calling 'media_result API) !

This leakage comes from the sqlite3 connection handler which is generated for each 'media_lightmediascanner_scan' call every time. We most close the connection and release the handler resources at the end of 'media_lightmediascanner_scan'  function (safer but lower performance) or keep the handler pointer as a global function and close it when media-device is pulled off (better performance).

==1063== 15,348,720 (32,208 direct, 15,316,512 indirect) bytes in 66 blocks are definitely lost in loss record 88 of 88
==1063== at 0x483E970: malloc (vg_replace_malloc.c:299)
==1063== by 0x574D419: ??? (in /usr/lib/libsqlite3.so.0.8.6)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The forth leakage is in 'on_interface_proxy_properties_changed' function, when iterating over 'changed_properties' as a GVariant ... The catched keys & subValues are not released  after usage. Here is memory leak report for 30 event rise with mentioned flash memory:

Memory leakage for 30 'media_added' & 'media_removed' event rises:

==1063== 19,899 (5,872 direct, 14,027 indirect) bytes in 245 blocks are definitely lost in loss record 80 of 88
==1063== at 0x483E970: malloc (vg_replace_malloc.c:299)
==1063== by 0x55291AB: g_malloc (in /usr/lib/libglib-2.0.so.0.5800.0)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 
 
At following you can find the Valgrind results for current mediascanner binding with 30 events rising (with the memory flash containing around 70 media files).

There is another minor leak belong to afb-daemon that I reported it here: SPEC-3126.