Bug 67451
| Summary: | memory leak in tty driver | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Filipe David Manana (fdmanana) |
| Component: | Console/Framebuffers | Assignee: | Alan (alan) |
| Status: | NEW --- | ||
| Severity: | high | CC: | alan, fdmanana |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 3.11.0 3.12.5 3.13-rc4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
Thanks, that ought to be enough information to trace it back as it comes from 'setfont' so I can trace the path that is apparently causing the leak. Added to the queue but it's not I think particularly urgent Ok, thank you Alan. Btw, if it leaks too much, can it freeze my machine? I've had a few freezes, and they seemed to (by coincidence maybe) have happened during a boot where kmemleak reported those leaks. I would not expect so although it is possible both are symptoms of some other bug of course. |
Often, while running a vanilla kernel from kernel.org (tested with 3.11.0, 3.12.5 and 3.13-rc4) while using gnome's terminal app, kmemleak reports the following leak: unreferenced object 0xffff8807f74d7b10 (size 512): comm "setfont", pid 819, jiffies 4294895521 (age 1420.336s) hex dump (first 32 bytes): 9c fe b1 f1 9b 9d 00 00 92 00 91 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8175f606>] kmemleak_alloc+0x26/0x50 [<ffffffff8118dd44>] kmem_cache_alloc_trace+0x114/0x200 [<ffffffff814b31b9>] set_inverse_transl+0x109/0x150 [<ffffffff814b357f>] con_set_unimap+0x1ef/0x2a0 [<ffffffff814ad0f2>] vt_ioctl+0x10e2/0x12a0 [<ffffffff8149fde8>] tty_ioctl+0x2a8/0xc80 [<ffffffff811b2946>] do_vfs_ioctl+0x96/0x570 [<ffffffff811b2eb1>] SyS_ioctl+0x91/0xb0 [<ffffffff8177ef12>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff8807f74d4d20 (size 512): comm "setfont", pid 819, jiffies 4294895521 (age 1420.336s) hex dump (first 32 bytes): 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................ 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ backtrace: [<ffffffff8175f606>] kmemleak_alloc+0x26/0x50 [<ffffffff8118dd44>] kmem_cache_alloc_trace+0x114/0x200 [<ffffffff814b31b9>] set_inverse_transl+0x109/0x150 [<ffffffff814b357f>] con_set_unimap+0x1ef/0x2a0 [<ffffffff814ad0f2>] vt_ioctl+0x10e2/0x12a0 [<ffffffff8149fde8>] tty_ioctl+0x2a8/0xc80 [<ffffffff811b2946>] do_vfs_ioctl+0x96/0x570 [<ffffffff811b2eb1>] SyS_ioctl+0x91/0xb0 [<ffffffff8177ef12>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff unreferenced object 0xffff8807e90f44a8 (size 1024): comm "setfont", pid 819, jiffies 4294895521 (age 1420.336s) hex dump (first 32 bytes): a3 00 a0 25 92 25 b1 00 a2 00 a5 00 a9 00 ae 00 ...%.%.......... c6 00 dd 00 e6 00 52 01 53 01 78 01 14 20 20 20 ......R.S.x.. backtrace: [<ffffffff8175f606>] kmemleak_alloc+0x26/0x50 [<ffffffff8118dd44>] kmem_cache_alloc_trace+0x114/0x200 [<ffffffff814b2ab0>] set_inverse_trans_unicode.isra.2+0x120/0x140 [<ffffffff814b358c>] con_set_unimap+0x1fc/0x2a0 [<ffffffff814ad0f2>] vt_ioctl+0x10e2/0x12a0 [<ffffffff8149fde8>] tty_ioctl+0x2a8/0xc80 [<ffffffff811b2946>] do_vfs_ioctl+0x96/0x570 [<ffffffff811b2eb1>] SyS_ioctl+0x91/0xb0 [<ffffffff8177ef12>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff I don't know exactly what the steps are to reproduce this, it happens not too often, but when it happens, I end up getting 50+ such leaks reported.