我一次又一次地发现自己做了一些中度愚蠢的事情,导致我的程序分配了它可以获得的所有内存,然后是一些.
这种事情曾经导致程序因"内存不足"错误而很快死亡,但是现在Windows会不顾一切地将这种不存在的内存提供给应用程序,事实上显然已经准备好自杀这样做.当然不是字面意思,但它会使可用的物理RAM匮乏如此严重,甚至运行任务管理器将需要半小时的交换(在所有失控的应用程序仍在分配越来越多的内存之后).
这种情况不会经常发生,但是当它发生时却是灾难性的.我通常不得不重置我的机器,导致数据不时丢失并且通常会带来很多不便.
你是否有任何关于使这种错误的后果不那么可怕的实用建议？也许某些注册表调整限制允许应用程序分配的最大虚拟内存量？或者某些CLR标志仅限于当前应用程序？(我通常在.NET中对自己这样做.)
("不要耗尽RAM"和"购买更多RAM"是没有用的 - 前者我无法控制,后者我已经完成了.)
我试图阻止学生代码在分配中运行,并拖延我的测试机器.我试过了
setrlimit(RLIMIT_DATA, r);
哪个r是持有限制的结构.但不幸的是,虽然这个限制停止brk并且sbrk分配,但是C库只是故障转移mmap并保持正确分配.
我也试过了
setrlimit(RLIMIT_AS, r)
并且这会使进程停止,但是这种补救措施太严重了 - 进程无法从ENOMEM错误中恢复,因为代码在遇到NULL返回的值时所进行的调用没有堆栈空间malloc().
我对二进制文件的控制有限,所以如果可以用系统调用,我宁愿这样做.但我需要一些方法来限制分配,而不会破坏流程的恢复能力.有没有人有建议？
更新:我找到了一个名为failmalloc的东西,但它不是很复杂,虽然我可以导致它失败,但我总是遇到gdb无法诊断的段错误.
进一步更新:我发现setrlimit(RLIMIT_AS, r) 它似乎做我想要的工作,至少在被不相关的模块中发生的故障之后引起了某些情况下,该段错误.除非有人想出一些有趣的东西(或保留问题的理由),否则我可能会删除这个问题.