user-0 提问: malloc函数在什么情况下会直接出现段错误而不是返回NULL

回复:
user: user-1
content: 不用看肯定其他地方越界。光看这代码肯定啥都看不出来。

user: user-2
content: 你加下malloc分配失败判断吧，会不会是分配失败又去free导致的错误呢？

user: user-3
content: #include <stdio.h> #include <malloc.h> #include <stdlib.h> void main(void) { 	char **list; 	list = (char**)malloc(200 * sizeof(char*));     if(list == NULL) { 		perror("mem error\n"); 		exit(1); 	}  }  VC6.0没有发现问题 你把你的运行崩后的提示截个图

user: user-0
content: 以下是用valgrind运行的结果，不知道有没有参考价值，valgrind我其实不太会用 本来应该更新到顶楼但不知怎么显示我没有权限，就加在这里了 valgrind --tool=memcheck --leak-check=full ./x 10gs_ligand.mol2  ==15439== Memcheck, a memory error detector ==15439== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==15439== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==15439== Command: ./x 10gs_ligand.mol2 ==15439==  ==15439== Invalid write of size 8 ==15439==    at 0x4C2F793: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==15439==    by 0x402A41: identify (id.c:149) ==15439==    by 0x401A26: target (read_mol2.c:95) ==15439==    by 0x400FB4: main (main.c:15) ==15439==  Address 0x591f208 is 0 bytes after a block of size 168 alloc'd ==15439==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==15439==    by 0x402911: identify (id.c:141) ==15439==    by 0x401A26: target (read_mol2.c:95) ==15439==    by 0x400FB4: main (main.c:15) ==15439==  ok n_pt: 21 key_num: 210 --15439-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --15439-- si_code=80;  Faulting address: 0x0;  sp: 0x802b9ddd0  valgrind: the 'impossible' happened:    Killed by fatal signal ==15439==    at 0x3805CF06: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==15439==    by 0x380216D4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==15439==    by 0x380218A2: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==15439==    by 0x3809DC03: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==15439==    by 0x380AC87C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)  sched status:   running_tid=1  Thread 1: status = VgTs_Runnable ==15439==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==15439==    by 0x40689C: key (key.c:44) ==15439==    by 0x40742D: distscore (distscore.c:165) ==15439==    by 0x400FD0: main (main.c:18)

user: user-0
content: 引用 10 楼 lovesmiles 的回复:[quote=引用 8 楼 bagademosuki 的回复:] [quote=引用 5 楼 lovesmiles 的回复:] 没看出这个malloc用法有什么问题，我更倾向于你的程序有其它的问题。  单独建一个程序测试这个用法看看。 我试了，把这个程序稍加修改单独运行没有问题。 我想问下这样怎么办。。。[/quote]  信息量太少了，你已经引导我们向你设想的问题方向去了。如果问题不出在malloc上面，你把malloc的代码贴出来我们也分析不出原因。[/quote] sorry...如果把全部代码贴出来的话，确实是挺多了，而且还需要很多输入文件，量很大，我觉得不是很合适。 另一方面，这个问题可能真的和之前有关，但他仍是在调用一个简单的malloc时出的错，从这里入手大概可以解决吧。。。我把valgrind的信息贴上来好了

user: user-4
content: 引用 8 楼 bagademosuki 的回复:[quote=引用 5 楼 lovesmiles 的回复:] 没看出这个malloc用法有什么问题，我更倾向于你的程序有其它的问题。  单独建一个程序测试这个用法看看。 我试了，把这个程序稍加修改单独运行没有问题。 我想问下这样怎么办。。。[/quote]  信息量太少了，你已经引导我们向你设想的问题方向去了。如果问题不出在malloc上面，你把malloc的代码贴出来我们也分析不出原因。

user: user-0
content: 引用 6 楼 mymtom 的回复:板子上跑的程序？ 不是，写来在PC上做计算的。

user: user-0
content: 引用 5 楼 lovesmiles 的回复:没看出这个malloc用法有什么问题，我更倾向于你的程序有其它的问题。  单独建一个程序测试这个用法看看。 我试了，把这个程序稍加修改单独运行没有问题。 我想问下这样怎么办。。。

user: user-0
content: 引用 4 楼 r_Jimy 的回复:你的编译环境是怎么样的，可能动态空间的分配确实受到了限制 另外，你将malloc返回的地址强转成二级指针没问题吗？ 我是UBUNTU 14.04 Linux guxiaoPC 3.8.0-32-generic #47-Ubuntu icc version 13.1.1 (gcc version 4.7.0 compatibility) 其它地方也有这种转换好像没有问题，void理论上应该可以随便转的吧

user: user-5
content: 板子上跑的程序？

user: user-4
content: 没看出这个malloc用法有什么问题，我更倾向于你的程序有其它的问题。  单独建一个程序测试这个用法看看。

user: user-2
content: 你的编译环境是怎么样的，可能动态空间的分配确实受到了限制 另外，你将malloc返回的地址强转成二级指针没问题吗？

user: user-0
content: 引用 1 楼 user-7 的回复:不至于，因为你分配的空间又不大。。。。  你可以把你的错误信息贴出来看看 n_pt: 21 key_num: 210 Segmentation fault (core dumped) 上面一行是这几行之前的输出，没有问题 下面就是报错，除了说是段错误没有什么有价值的信息了

user: user-6
content: 进程意外退出会在当前目录下产生‘core’文件或形如‘core.数字’的文件比如‘core.1234’ 使用命令 gdb 运行程序名 core或core.数字 进入gdb然后使用bt命令 可以查看进程意外退出前函数调用的堆栈，内容为从上到下列出对应从里层到外层的函数调用历史。 如果进程意外退出不产生core文件，参考“ulimit -c core文件最大块大小”命令

user: user-7
content: 不至于，因为你分配的空间又不大。。。。  你可以把你的错误信息贴出来看看