Memory leak issue with vivante graphics driver 3.10.17_1.0.2

[vikaspatil]

Dear All,

When I run GLES2.0 sdk sample application continuously with Kmemleak enabled (which provides a way of detecting possible kernel memory leaks) for 3.10.17_1.0.2 based custom kernel I see below pasted log(i.e. memory leak) from vivante's graphics driver. As a result application window freezes on display after running it for longer duration (say 8 to 12 hours of running) or sometime doesn't show on display. In this scenario platform seems to stable, means I can work with it.

I have tried with  "07_EnvironmentMapping" and "09_VIV_direct_texture" example application and one more application which I have written for rear-view-camera using

v4l2/X11/GLES2.0(glTexDirectInvalidateVIV and glTexDirectVIV). Result are same, application window freezes or doesn't show even application seems to be running and also shows following memory leak log.

Does anyone come across this issue?

Is this known issue and fixed?

How to fix this issue or avoid this issue?

**************************************************************************************************

kmemleak log:

root@imx6solosabreauto:/vikas/GLES20_X11# echo scan > /sys/kernel/debug/kmemleak

root@imx6solosabreauto:/vikas/GLES20_X11# cat /sys/kernel/debug/kmemleak

unreferenced object 0x8c3a8000 (size 8224):

  comm "systemd-journal", pid 73, jiffies 4294937611 (age 310.860s)

  hex dump (first 32 bytes):

    73 01 00 00 00 00 00 00 68 6e 00 00 06 00 00 00  s.......hn......

    01 00 00 00 14 80 3a 8c 14 80 3a 8c 36 2c 33 37  ......:...:.6,37

  backtrace:

    [<800d4458>] create_object+0x120/0x240

    [<803a6a00>] kmemleak_alloc+0x44/0x78

    [<800cfb38>] kmalloc_order_trace+0x4c/0xb4

    [<80026488>] devkmsg_open+0x50/0xa8

    [<80228ca4>] memory_open+0x78/0x94

    [<800dda9c>] chrdev_open+0x118/0x144

    [<800d7c04>] do_dentry_open.isra.56+0x1bc/0x26c

    [<800d7cd8>] finish_open+0x24/0x38

    [<800e6494>] do_last.isra.43+0x8a4/0xa68

    [<800e6710>] path_openat+0xb8/0x3d4

    [<800e6d24>] do_filp_open+0x3c/0x88

    [<800d8f84>] do_sys_open+0xf4/0x1dc

    [<800d909c>] SyS_open+0x30/0x34

    [<8000e140>] ret_fast_syscall+0x0/0x30

    [<ffffffff>] 0xffffffff

unreferenced object 0xa0c43000 (size 65536):

  comm "09_VIV_direct_t", pid 351, jiffies 4294960427 (age 82.700s)

  hex dump (first 32 bytes):

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

  backtrace:

    [<800d4458>] create_object+0x120/0x240

    [<803a6a00>] kmemleak_alloc+0x44/0x78

    [<800c7600>] __vmalloc_node_range+0x1b4/0x1f4

    [<800c7688>] __vmalloc_node+0x48/0x54

    [<800c76cc>] vmalloc+0x38/0x44

    [<802a782c>] gckOS_AllocateMemory+0x34/0x64

    [<802a789c>] gckOS_Allocate+0x40/0x50

    [<802b82ec>] gckCONTEXT_Construct+0xdc/0x2c8

    [<802afd2c>] gckCOMMAND_Attach+0x54/0x94

    [<802ae42c>] gckKERNEL_Dispatch+0x1264/0x1614

    [<802a65d8>] drv_ioctl+0x1cc/0x288

    [<800e8394>] vfs_ioctl+0x38/0x4c

    [<800e8e94>] do_vfs_ioctl+0x518/0x56c

    [<800e8f60>] SyS_ioctl+0x78/0xc0

    [<8000e140>] ret_fast_syscall+0x0/0x30

    [<ffffffff>] 0xffffffff

unreferenced object 0xa0c54000 (size 114688):

  comm "09_VIV_direct_t", pid 351, jiffies 4294960428 (age 82.690s)

  hex dump (first 32 bytes):

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

  backtrace:

    [<800d4458>] create_object+0x120/0x240

    [<803a6a00>] kmemleak_alloc+0x44/0x78

    [<800c7600>] __vmalloc_node_range+0x1b4/0x1f4

    [<800c7688>] __vmalloc_node+0x48/0x54

    [<800c76cc>] vmalloc+0x38/0x44

    [<802a782c>] gckOS_AllocateMemory+0x34/0x64

    [<802a789c>] gckOS_Allocate+0x40/0x50

    [<802b82ec>] gckCONTEXT_Construct+0xdc/0x2c8

    [<802afd2c>] gckCOMMAND_Attach+0x54/0x94

    [<802ae42c>] gckKERNEL_Dispatch+0x1264/0x1614

    [<802a65d8>] drv_ioctl+0x1cc/0x288

    [<800e8394>] vfs_ioctl+0x38/0x4c

    [<800e8e94>] do_vfs_ioctl+0x518/0x56c

    [<800e8f60>] SyS_ioctl+0x78/0xc0

    [<8000e140>] ret_fast_syscall+0x0/0x30

    [<ffffffff>] 0xffffffff

unreferenced object 0xa0c71000 (size 172032):

  comm "09_VIV_direct_t", pid 351, jiffies 4294960433 (age 82.640s)

  hex dump (first 32 bytes):

    c0 e0 83 80 40 01 68 80 c0 ef 67 80 40 25 87 80  ....@.h...g.@%..

    80 25 87 80 a0 25 87 80 77 7c d3 fe ef dd 59 bd  .%...%..w|....Y.

  backtrace:

    [<800d4458>] create_object+0x120/0x240

    [<803a6a00>] kmemleak_alloc+0x44/0x78

    [<800c7600>] __vmalloc_node_range+0x1b4/0x1f4

    [<800c7688>] __vmalloc_node+0x48/0x54

    [<800c76cc>] vmalloc+0x38/0x44

    [<802a782c>] gckOS_AllocateMemory+0x34/0x64

    [<802a789c>] gckOS_Allocate+0x40/0x50

    [<802b8588>] gckCONTEXT_Update+0x94/0x454

    [<802af58c>] gckCOMMAND_Commit+0x2ec/0xa38

    [<802adba0>] gckKERNEL_Dispatch+0x9d8/0x1614

    [<802a65d8>] drv_ioctl+0x1cc/0x288

    [<800e8394>] vfs_ioctl+0x38/0x4c

    [<800e8e94>] do_vfs_ioctl+0x518/0x56c

    [<800e8f60>] SyS_ioctl+0x78/0xc0

    [<8000e140>] ret_fast_syscall+0x0/0x30

    [<ffffffff>] 0xffffffff

root@imx6solosabreauto:/vikas/GLES20_X11#

Regards,

Vikash

[richardbuchmann]

Same problem here with 3.10.9-1.0.0-hfp-r0.

Is there any workaround or fix ?

Regards,

Richard

[Bio_TICFSL]

Hi Vikash,

Correct! This is a Memory leak Bug, the issue dissapear when you comment out the glTexDirectVIV, Hope developers provides the patch with fix soon.

Regards

[vikaspatil]

Hi,

This memory leak issues doesn't seem to related to glTexDirectVIV() only, it is coming with glTexDirectVIVMap() and other apis too. So it should be the generic issue with graphics driver. As I have tested it with 07_EnvironmentMapping and seeing the leak.

Do you know when is the plan to fix this?

Regards,

Vikash

[vikaspatil]

Hi,

Thanks for the information. Do you know if there is any plan to fix this issue and when it will be available?

Regards,

Vikash