AnsweredAssumed Answered

Memory leak issue with vivante graphics driver 3.10.17_1.0.2

Question asked by vikash patil on May 6, 2015
Latest reply on Mar 31, 2017 by Richard Buchmann

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

Outcomes