New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak #191
Comments
I wrote a small script which demonstrates the issue. With |
Here is a version of your python code in C. Here is an extract of what valgrind spits on this code (full output here): ==1293489== 32 bytes in 1 blocks are definitely lost in loss record 869 of 3,760
==1293489== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1293489== by 0x5C456E7: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.515.105.01)
==1293489== by 0x5C46013: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.515.105.01)
==1293489== by 0x5C46537: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.515.105.01)
==1293489== by 0x48DE7F3: alloc_device_array (ufo-buffer.c:177)
==1293489== by 0x48E0CFE: ufo_buffer_get_device_array (ufo-buffer.c:1008)
==1293489== by 0x57E39015: ufo_polar_coordinates_task_process (ufo-polar-coordinates-task.c:208)
==1293489== by 0x48F4F20: ufo_task_process (ufo-task-iface.c:150)
==1293489== by 0x48F38B9: run_task (ufo-scheduler.c:212)
==1293489== by 0x4C9DA50: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==1293489== by 0x4A83B42: start_thread (pthread_create.c:442)
==1293489== by 0x4B14BB3: clone (clone.S:100)
==1293489==
==1293489== 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 2,221 of 3,760
==1293489== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1293489== by 0x4C77738: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==1293489== by 0x4C8EB74: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==1293489== by 0x4C8F277: g_slist_append (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
==1293489== by 0x48ECE88: ufo_plugin_manager_get_plugin (ufo-plugin-manager.c:192)
==1293489== by 0x48ED51A: ufo_plugin_manager_get_task (ufo-plugin-manager.c:342)
==1293489== by 0x1094AD: get_memory_in (resources_leak.c:104)
==1293489== by 0x1096D7: cartesian_to_polar (resources_leak.c:154)
==1293489== by 0x1099EF: main (resources_leak.c:204) Idea for the second leak: I believe that this might be related . When the plugin_manager class is finalized, the priv->modules are not freed as explained in the comment:
For the first leak, the last traced function causing the leak in ufo is found here. This section allocates a buffer object in openCl. However it is correctly freed here when the class is finalized. |
Hm, I see there is no clRetainMemObject call when creating the device array, which is weird. Second, can you check the reference count on release? If that doesn't say 0 we know where the problem is. |
When I use the same
Ufo.Resources
throughout my python program, all is fine. However, if new resources are generated every time aUfo.Scheduler
is created then not everything is freed. From a first glance at the resources there shouldn't be a leak, and yet there is. @gabs1234 we should look into this.The text was updated successfully, but these errors were encountered: