Returning GArray in a C function leaks GPtrArray

Note of the GArray versus the GPtrArray (extra Ptr in the leak).

To be able to test this one would need git master of libical compiled with introspection and libical-glib. Then running:

   $ G_SLICE=always-malloc valgrind --leak-check=full --show-leak-kinds=definite \
       --num-callers=30 /usr/bin/python3 src/test/libical-glib/recurrence.py

produces these memory leaks:

==18772== 160 (32 direct, 128 indirect) bytes in 1 blocks are definitely lost in loss record 4,070 of 5,551
==18772==    at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==18772==    by 0xE3AAB02: g_malloc (gmem.c:99)
==18772==    by 0xE3C51C2: g_slice_alloc (gslice.c:1025)
==18772==    by 0xE36B1EB: g_ptr_array_sized_new (garray.c:915)
==18772==    by 0xDCA2B66: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0xDC9EC0C: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0xDCA06DB: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0x4F4215A: _PyObject_FastCallDict (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FB73F0: ??? (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FFC089: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FE2CA7: PyEval_EvalCodeEx (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FE3BCA: PyEval_EvalCode (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x50629E1: ??? (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x5062D89: PyRun_FileExFlags (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x5064B3F: PyRun_SimpleFileExFlags (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x5065C5A: Py_Main (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x108CA7: main (in /usr/bin/python3.6)
==18772== 
==18772== 44,800 (896 direct, 43,904 indirect) bytes in 28 blocks are definitely lost in loss record 5,547 of 5,551
==18772==    at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==18772==    by 0xE3AAB02: g_malloc (gmem.c:99)
==18772==    by 0xE3C51C2: g_slice_alloc (gslice.c:1025)
==18772==    by 0xE36B1EB: g_ptr_array_sized_new (garray.c:915)
==18772==    by 0xDCA2B66: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0xDC9EC0C: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0xDCA06DB: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0xDC93B62: ??? (in /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so)
==18772==    by 0x4F4215A: _PyObject_FastCallDict (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FB73F0: ??? (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FFC089: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FE2CA7: PyEval_EvalCodeEx (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x4FE3BCA: PyEval_EvalCode (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x50629E1: ??? (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x5062D89: PyRun_FileExFlags (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x5064B3F: PyRun_SimpleFileExFlags (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x5065C5A: Py_Main (in /usr/lib64/libpython3.6m.so.1.0)
==18772==    by 0x108CA7: main (in /usr/bin/python3.6)

Trying to disable these lines in the recurrence.py:

   by_second = recurrence.get_by_second_array()
   # The value is dependent on the libical version.
   assert len(by_second) == 61 or len(by_second) == 62

hides one of the memory blocks, thus it's about the recurrence.get_by_second_array() and the like functions, but they are defined as:

/**
 * i_cal_recurrence_get_by_second_array:
 * @recur: The #ICalRecurrence.
 *
 * Get the by_second array from #ICalRecurrence. The array size if I_CAL_BY_SECOND_SIZE.
 *
 * Returns: (transfer full) (element-type gshort): The by_second of #ICalRecurrence.
 *
 * Since: 1.0
 *
 **/
GArray *i_cal_recurrence_get_by_second_array (ICalRecurrence *recur);

with no mentioning of the GPtrArray, which makes me believe the reported memory leak is from elsewhere than from the libical-glib code (being it in libical-glib the backtrace reported from valgrind would include libical-glib .c files).