Kernel memory leak using openCL ?

[phdm]

Hi all,

I have a simple openCL kernel called repeatedly on a image stream.  The repeated  part is :

cl_int err;

/* Create memory buffers */
input_buffer = clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR, input_size, src, &err);
opencl_check(err, "Could not create the input buffer.");
output_buffer = clCreateBuffer(context, CL_MEM_WRITE_ONLY | CL_MEM_USE_HOST_PTR, output_size, dest, &err);
opencl_check(err, "Could not create the output buffer.");

/* Set OpenCL kernel arguments */
err = clSetKernelArg(kernel, 0, sizeof(cl_mem), &input_buffer);
err |= clSetKernelArg(kernel, 1, sizeof(cl_mem), &output_buffer);
opencl_check(err, "Could not set the kernel arguments.");

/* Execute OpenCL kernel */
size_t global_work_size[2];
global_work_size[0] = width;
global_work_size[1] = height;

err = clEnqueueNDRangeKernel(command_queue, kernel, 2, NULL, global_work_size, NULL, 0, NULL, NULL);
opencl_check(err, "Could not enqueue the kernel execution command.");

/* Transfer result from output buffer */
err = clEnqueueReadBuffer(command_queue, output_buffer, CL_TRUE, 0, output_size, dest, 0, NULL, NULL);
opencl_check(err, "Could not read the output buffer.");

err = clReleaseMemObject(input_buffer);
opencl_check(err, "Could not release input buffer.");
err = clReleaseMemObject(output_buffer);
opencl_check(err, "Could not release output buffer.");

The image transformation works perfectly, but this program is plagued by a kernel memory leak, that I cannot spot.

I work with the g3-4.1.15_1.2.0_ga kernel and the 5.0.11.p8.6+hfp vivante libraries.  Is there an obvious mistake in the above code that could lead to a kernel memory leak ?

Alternatively, is there a way to track memory leaks in galcore driver ?

I must add that valgrind does not indicate any user memory leak.

I must also add that the kernel memory leaked is not even freed when the program terminates.

It seems that the memory is freed when I unload (rmmod) and reload (modprobe) the galcore module.

I have estimated the leak rate, by disabling as many processes as I could, and logging 'free' answers.  My estimate is 2300 bytes leaked per iteration (= frame, = kernel call).  This is not the size of my frames (neither input_size, nor output_size)

Thanks in advance

[Bio_TICFSL]

hi Philippe,

Could you please add your log, and your app file?

thanks

[phdm]

I have reduced my gstreamer pipeline to a simple standalone program that reproduce the problem.

I let it run on a otherwise inactive imx6q board, and I monitor the free ram using the following script :

PREVMIN=999999999

while true; do set -- `free | sed -n 2p`; if [ $4 -lt ${PREVMIN} ]; then echo `date` $4; PREVMIN=$4; fi; sleep 1; done

And I see my free mem decreasing continuously !!!

I have attached the testcase

[phdm]

Of course, but I don't know what you mean precisely by log or app file.  The code I showed is actually the heart of a gstreamer plugin to transform bayer to downscaled rgb.  Here is the cl file, which is compiled once in the init phase of the plugin :

__kernel void bayer2rgb_half(__global uchar *bayer, __global uchar *rgb)
{
int id_x = get_global_id(0);
int id_y = get_global_id(1);
int bayer_width = 2 * get_global_size(0);
int rgb_width = get_global_size(0);

int r = bayer[(2 * id_y + 1) * bayer_width + 2 * id_x + 1];
int g = ((int)bayer[2 * id_y * bayer_width + 2 * id_x + 1] + (int)bayer[(2 * id_y + 1) * bayer_width + 2 * id_x]) / 2; // Casts from uchar to int needed otherwise risk of overflow;
int b = bayer[2 * id_y * bayer_width + 2 * id_x];

int rgb_id = id_y * rgb_width + id_x;
rgb[3 * rgb_id] = r;
rgb[3 * rgb_id + 1] = g;
rgb[3 * rgb_id + 2] = b;
}

I notice the kernel memory leak because after some time of running a very simple pipeline :

gst-launch-1.0 v4l2src ! video/x-bayer ! ourbayer2rgb ! fakesink

the kernel starts the oom procedure and kill random programs; this does not happen when

I do not run this pipeline.  On our board with 500Mb free when starting the pipeline, it takes several hours (at 4 fps)

before the oom procedure starts.