Ubuntu中文论坛

shellex 写了：ls说俄虾米啊，都不对路
我告诉你。linux上gcc在堆上会分配冗余空间,，貌似按照8还是16 byte的倍数分配。所以可以...

dbzhang800 写了：

shellex 写了：ls说俄虾米啊，都不对路
我告诉你。linux上gcc在堆上会分配冗余空间,，貌似按照8还是16 byte的倍数分配。所以可以...

楼主关注的应该不是这个问题。

可以负责任的告诉你，楼主的这个程序不止是在linux下gcc编译后可以执行，而且windows下不论用gcc还是vc编译后也都可以正常运行。
而且在Solaris下不论你用gcc，还是sun的的CC编译器，生成的可执行文件都是可正常执行的。


我想强调的是，用指针或数组的时候，要自己检查自己用的是不是正确，因为这类的错误编译器往往帮不上忙。而且会给你一种太平的假象。

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

char *test( int num )
{
char *p = (char *)malloc( sizeof( char )*num );
return p;
}

int main( void )
{
char *p = NULL;
char *q = NULL;
p = test( 10 ); //故意是申请的空间小于要拷贝的内容
q = (char *)malloc(sizeof(char)*10);
strcpy( q, "hello" );
printf( "q=%s\n", q);
strcpy( p , "hello! world rutrueiyteiy " );
printf( "now q=%s\n", q);
printf("string *p: %s\n",p);
while( *p != '\0' )
printf("%c ",*p++);

return 0;
}

$ ./a.out
q=hello
now q=rueiyteiy
string *p: hello! world rutrueiyteiy
h e l l o ! w o r l d r u t r u e i y t e i y

检查core dump文件
今晚吕烁问了一个怎样利用core dump文件调试程序bug的问题。两年前翻译过一章调试的英文资料。很久没有用都忘的差不多了。找到了《An Introduction to GCC - for the GNU compilers gcc and g++》中的一节，用了半个多小时翻译出来，权且做为一个资料以备将来参考。《An Introduction to GCC - for the GNU compilers gcc and g++》是GCC爱好者必看的一本入门级的书。GCC最早的开发者－Richard M. Stallman为这本书做序。

对应的英文引自http://www.network-theory.co.uk/docs/gccintro/gccintro_38.html。
5.1 检查core文件（内核转储文件）
除了允许程序在调试器的控制下运行外，-g选项一个非常有用的功能是利用“core dump”检查程序崩溃的原因。
当一个程序异常结束时（比如崩溃），操作系统能够将程序崩溃时内存中的状态信息写入一个core文件（通常这个文件命名为core）。这个文件经常被称为 core dump(内核转储).与-g选项产生的符号表信息结合，这个core dump能用来找到程序在哪一行异常结束了，以及程序运行到这一行时相关变量的值。
这个特性在软件开发当中和软件发布后都是非常有用的，这是因为可以从程序崩溃的现场调查有关问题。
下面的简单程序中包含一个非法访存的bug，我们将用这个程序来产生一个core文件。

int foo (int *p);

int
main (void)
{
int *p = 0; /* null pointer */
return foo (p);
}

int
foo (int *p)
{
int y = *p;
return y;
}
这个程序试图解引用一个空指针p，众所周知，这是一个非法的操作。在大多数系统上，这将产生异常结束。
为了能找到程序崩溃的原因，我们需用-g选项来编译这个程序。
$ gcc -Wall -g null.c
需要注意的是空指针访问仅在运行时出现异常，因此选项-Wall并不产生任何警告。
在x86 GNU/Linux系统上运行这个可执行文件，将会引起操作系统异常终止这个程序：
$ ./a.out
Segmentation fault (core dumped)
只要出现错误信息'core dumped'，操作系统就会在当前目录产生一个"core"文件。这个core文件包含程序结束时的内存信息的副本。术语“段错误”有时指程序试图访问已分配给它的内存之外的一个受限内存“段”。
一些操作系统配置为缺省不生成core文件。这样做的理由是基于core文件可能体积很大因而可能会很快占满剩余磁盘空间。在GNU Bash shell中，用命令ulimit -c 可以控制core文件的最大体积。如果用上述命令得到的是0，那么不产生core文件。当前的大小限制用下列的命令可以获知。
$ ulimit －c
0
如果结果是0， 如上所示，那么可以用下面的命令允许生成任意大小的core文件。
ulimit -c unlimited
注意上面的设置仅在当前shell有效。为了在将来的会话中有效，可以将上面的命令加入一个登录文件，比如GNU Bash shell的.bash_profile文件。
core文件可以用下面的命令装入GDB中调试。
gdb EXECUTALBE_FILE CORE_FILE
注意原来的可执行文件和core文件在调试中都是必须的。不能在没有相应的可执行文件的情况下调试一个core文件。在这个例子中，我们用下面的命令装入可执行文件和core文件：
$ gdb a.out core
调试器立即打印诊断信息，并显示程序崩溃的行号（第13行）：
$ gdb a.out core
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x080483ed in foo (p=0x0) at null.c:13
13 int y = *p;
(gdb)
最后一行(gdb)是GDB的提示符，它提示后面可以继续输入命令。
为了弄清楚程序崩溃的原因，我们在调试器中用print命令显示指针p的值。
(gdb) print p
$1 = (int *) 0x0
这个信息告诉我们p是一个整形的空指针(0x0)，因此我们知道指针解耦访问*p导致了程序崩溃。

dbzhang800 写了：

shellex 写了：ls说俄虾米啊，都不对路
我告诉你。linux上gcc在堆上会分配冗余空间,，貌似按照8还是16 byte的倍数分配。所以可以...

楼主关注的应该不是这个问题。

可以负责任的告诉你，楼主的这个程序不止是在linux下gcc编译后可以执行，而且windows下不论用gcc还是vc编译后也都可以正常运行。
而且在Solaris下不论你用gcc，还是sun的的CC编译器，生成的可执行文件都是可正常执行的。


我想强调的是，用指针或数组的时候，要自己检查自己用的是不是正确，因为这类的错误编译器往往帮不上忙。而且会给你一种太平的假象。