Linux数组容量上限问题

Altkuhl

我们有很多台server，都是AMDx86-64，操作系统都是 Redhat Enterprise Release。

我有一个已经编译好的ELF文件，是在一台如下配置的server上编译的：
Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

这个ELF文件不仅在这样的server上运行正确，而且在如下配置的server上也运行正确：
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

但是奇怪的是，它在下面这台server上就每次都发生 Segmentation fault：
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

后来debug发现，这个故障的原因是数组定义得太大：

#define DBUF_SIZE 16777216
...
char dbuf_in[DBUF_SIZE];

我把16777216改成4294304就好了。


我的问题是，同样的硬件，同样是 Redhat Enterprise Linux，只是Linux的version不一样，怎么更高版本的Linux只能允许更小的数组定义呢？
而且还是已经编译好的ELF文件，而不是重新编译。

这个数组容量是由什么决定和影响的呢？有没有可能调整呢？

谢谢。

fdl19881

不知道，只是觉得这么大数组为什么不用malloc分配呢

Altkuhl

我相信，应该会有办法调整这个容量。看看还有没有别的高手回答。
但是改用动态分配内存确实是个很好的选择。我原来使用过calloc，但是没有使用过malloc。
这次我从直接定义数组开始，主要是为了程序简单。我本来以为空间会够，哪知道还是不一定够。

crazyhadoop

回复 1# Altkuhl


    个人目测不是因为空间开的大，很可能是因为ELF环境而导致的问题。linux下很少像win拷贝程序用来用去的吧，除非是一些跟环境要求不高的动态库，这也是很少数。你可以试试源码重新编译一下

Altkuhl

我试过了。在这台**器上重新编译，也是如果用16777216就发生 Segmentation fault，如果用4294304就运行正确。

_print

运行 ulimit -a
有类似
stack size              (kbytes, -s) 10240
这个表示栈的大小，你将数组定义得太大，而这个数组是在栈上的，发生栈溢出，出现内存错误。 ulimit -s可以设置栈大小。

大的数组，自动变动，最好在堆上分配，即malloc方式。

Altkuhl

原来是堆栈容量问题。确实，我这个数组是定义在一个被调用的函数中的。
那么，假如在主程序中定义这么大的数组，就没有问题了是吗？

另外，请问， ulimit -s 设置栈大小，是只对当前这个 shell terminal 有效吗？
还有，用 calloc 和 malloc，各自有什么优缺点？分别更加适用于什么情况？