Qt应用程序因为内存不足(OOM)

Qt应用程序因为内存不足(OOM),第1张

概述Qt应用程序因为内存不足(OOM)

我在embedded式linux平台上运行Qt应用程序。 该系统有128 MB RAM,512MB NAND,无交换。 应用程序使用外设的自定义库,其余的都是Qt和c / c ++库。 该应用程序也使用sqlite3。

2-3小时后,机器启动运行速度非常慢,shell命令需要10秒左右才能响应。 最终机器挂起,最后OOM杀手杀死应用程序,系统开始正常运行。

在使用top命令进行了一些系统内存观察之后,发现在应用程序运行时,系统空闲内存正在减less,而slab继续增加。 这些是下面给出的顶部的快照。 该应用程序被命名为xyz 。

在申请开始时:

屏蔽图书馆泄漏的应用程序

linux / C ++:获取用户的目录没有泄漏

如何用C库在Python程序中刷新内存?

使用valgrind在MysqL c ++客户端中查找内存泄漏

使用AFNetworking 3.1.0的iOS 10.2上的http2内存泄漏

Mem total:126164 anon:3308 map:8436 free:32456 slab:60936 buf:0 cache:27528 dirty:0 write:0 Swap total:0 free:0 PID VSZ VSZRW^ RSS (SHR) DIRTY (SHR) STACK COMMAND 776 29080 9228 8036 528 968 0 84 ./xyz -qws 781 3960 736 1976 1456 520 0 84 sshd: root@notty 786 3676 680 1208 764 416 0 88 /usr/libexec/sftp-server 770 3792 568 1948 1472 464 0 84 {sshd} sshd: root@pts/0 766 3792 568 956 688 252 0 84 /usr/sbin/sshd 388 1864 284 552 332 188 0 84 udevd --daemon 789 2832 272 688 584 84 0 84 top 774 2828 268 668 560 84 0 84 -sh 709 2896 268 556 464 80 0 84 /usr/sbin/inetd 747 2828 268 596 516 68 0 84 /sbin/getty -L ttymxc0 115200 vt100 777 2824 264 444 368 68 0 84 tee out.log 785 2824 264 484 416 68 0 84 sh -c /usr/libexec/sftp-server 1 2824 264 556 488 64 0 84 init

一段时间后 :

Mem total:126164 anon:3312 map:8440 free:9244 slab:83976 buf:0 cache:27584 dirty:0 write:0 Swap total:0 free:0 PID VSZ VSZRW^ RSS (SHR) DIRTY (SHR) STACK COMMAND 776 29080 9228 8044 528 972 0 84 ./xyz -qws 781 3960 736 1976 1456 520 0 84 sshd: root@notty 786 3676 680 1208 764 416 0 88 /usr/libexec/sftp-server 770 3792 568 1948 1472 464 0 84 {sshd} sshd: root@pts/0 766 3792 568 956 688 252 0 84 /usr/sbin/sshd 388 1864 284 552 332 188 0 84 udevd --daemon 789 2832 272 688 584 84 0 84 top 774 2828 268 668 560 84 0 84 -sh 709 2896 268 556 464 80 0 84 /usr/sbin/inetd 747 2828 268 596 516 68 0 84 /sbin/getty -L ttymxc0 115200 vt100 777 2824 264 444 368 68 0 84 tee out.log 785 2824 264 484 416 68 0 84 sh -c /usr/libexec/sftp-server 1 2824 264 556 488 64 0 84 init

有趣的是,我看不到涉及应用程序本身的顶级输出的任何重大变化。 最终应用程序被杀害,之后的最高输出:

Mem total:126164 anon:2356 map:916 free:2368 slab:117944 buf:0 cache:1580 dirty:0 write:0 Swap total:0 free:0 PID VSZ VSZRW^ RSS (SHR) DIRTY (SHR) STACK COMMAND 781 3960 736 708 184 520 0 84 sshd: root@notty 786 3724 728 736 172 484 0 88 /usr/libexec/sftp-server 770 3792 568 648 188 460 0 84 {sshd} sshd: root@pts/0 766 3792 568 252 0 252 0 84 /usr/sbin/sshd 388 1864 284 188 0 188 0 84 udevd --daemon 819 2832 272 676 348 84 0 84 top 774 2828 268 512 324 96 0 84 -sh 709 2896 268 80 0 80 0 84 /usr/sbin/inetd 747 2828 268 68 0 68 0 84 /sbin/getty -L ttymxc0 115200 vt100 785 2824 264 68 0 68 0 84 sh -c /usr/libexec/sftp-server 1 2824 264 64 0 64 0 84 init

dmesg显示:

sh invoked oom-killer: gfp_mask=0xd0,order=2,oomkilladj=0 [<c002d4c4>] (unwind_backtrace+0x0/0xd4) from [<c0073ac0>] (oom_kill_process+0x54/0x1b8) [<c0073ac0>] (oom_kill_process+0x54/0x1b8) from [<c0073f14>] (__out_of_memory+0x154/0x178) [<c0073f14>] (__out_of_memory+0x154/0x178) from [<c0073fa0>] (out_of_memory+0x68/0x9c) [<c0073fa0>] (out_of_memory+0x68/0x9c) from [<c007649c>] (__alloc_pages_nodemask+0x3e0/0x4c8) [<c007649c>] (__alloc_pages_nodemask+0x3e0/0x4c8) from [<c0076598>] (__get_free_pages+0x14/0x4c) [<c0076598>] (__get_free_pages+0x14/0x4c) from [<c002f528>] (get_pgd_slow+0x14/0xdc) [<c002f528>] (get_pgd_slow+0x14/0xdc) from [<c0043890>] (mm_init+0x84/0xc4) [<c0043890>] (mm_init+0x84/0xc4) from [<c0097b94>] (bprm_mm_init+0x10/0x138) [<c0097b94>] (bprm_mm_init+0x10/0x138) from [<c00980a8>] (do_execve+0xf4/0x2a8) [<c00980a8>] (do_execve+0xf4/0x2a8) from [<c002afc4>] (sys_execve+0x38/0x5c) [<c002afc4>] (sys_execve+0x38/0x5c) from [<c0027d20>] (ret_fast_syscall+0x0/0x2c) Mem-info: DMA per-cpu: cpu 0: hi: 0,btch: 1 usd: 0 normal per-cpu: cpu 0: hi: 42,btch: 7 usd: 0 Active_anon:424 active_file:11 inactive_anon:428 inactive_file:3 unevictable:0 dirty:0 writeback:0 unstable:0 free:608 slab:29498 mapped:14 pagetables:59 bounce:0 DMA free:692kB min:268kB low:332kB high:400kB active_anon:0kB inactive_anon:0kB active_file:4kB inactive_file:0kB unevictable:0kB present:24384kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 103 103 normal free:1740kB min:1168kB low:1460kB high:1752kB active_anon:1696kB inactive_anon:1712kB active_file:40kB inactive_file:12kB unevictable:0kB present:105664kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 692kB normal: 377*4kB 1*8kB 4*16kB 1*32kB 2*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1740kB 30 total pagecache pages 0 pages in swap cache Swap cache stats: add 0,delete 0,find 0/0 Free swap = 0kB Total swap = 0kB 32768 pages of RAM 687 free pages 1306 reserved pages 29498 slab pages 59 pages shared 0 pages swap cached Out of memory: kill process 774 (sh) score 339 or a child Killed process 776 (xyz)

所以很明显,有一个内存泄漏,它必须是我的应用程序,因为我的应用程序被杀害。 但是我没有从程序中做任何malloc 。 我已经注意限制variables的范围,以便在它们被使用之后被释放。 所以我完全丧失了为什么最高产量的板坯在增加。 我曾尝试http://valgrind.org/docs/manual/faq.HTML#faq.reports,但没有奏效。

目前试图在桌面上使用Valgrind(因为我已经阅读它只适用于arm皮层)来检查我的业务逻辑。

添加信息:

root@freescale ~/Application/app$ uname -a linux freescale 2.6.31-207-g7286c01 #2053 Fri Jun 22 10:29:11 IST 2012 armv5tejl GNU/linux Compiler : arm-none-linux-gnueabi-4.1.2 glibc2.5 cpp libs : libstdc++.so.6.0.8 Qt : 4.7.3 libs

任何指针将不胜感激…

Delphi 7中使用WMI的内存泄漏

windows堆分配调用堆栈 – 奇怪的调用堆栈

有没有办法find使用核心文件泄漏的内存?

堆在windbg没有显示堆积如山

.Net越来越多的内存问题

我不认为这个问题是直接在你的代码中。 原因很明显:您的应用程序空间不会增加(RSS和VSW都不会增加)。

但是,您确实看到了增加的板坯数量。 你不能在应用程序中使用或增加平板的数量 – 这是一个内核专用的东西。

从我的头顶开始,板坯尺寸增加的一些明显原因是:

你从来没有真正关闭网络套接字

你读了很多文件,但从来没有关闭它们

你使用许多ioctls

我会运行strace,看看它的输出了一段时间。 strace截取与内核的交互。 如果你有内存问题,我希望重复调用brk()。 如果您还有其他问题,您会看到重复的电话打开而没有关闭。

如果您有一些数据结构分配,请检查添加子项的正确性等。我的代码中有类似的错误。 另外,如果您对数据库进行大型和大型查询,则可能会使用更多的RAM内存。 尝试找到一些内存泄漏检测器,以查找是否有任何泄漏。

总结

以上是内存溢出为你收集整理的Qt应用程序因为内存不足(OOM)全部内容,希望文章能够帮你解决Qt应用程序因为内存不足(OOM)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/1289935.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-09
下一篇 2022-06-09

发表评论

登录后才能评论

评论列表(0条)

保存