ubuntu 段错误，ubuntu grub》命令修复方法
大家好，关于ubuntu 段错误很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于ubuntu grub>命令修复方法的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
linux c 段错误如何定位
1.段错误是什么
一句话来说，段错误是指访问的内存超出了系统给这个程序所设bai定的内存空间，例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义（参考Answers.com）：
A segmentation fault(often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed(e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.
Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used,"segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.
On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.
2.段错误产生的原因
2.1访问不存在的内存地址
#include<stdio.h>
#include<stdlib.h>
void main()
{
int*ptr= NULL;
*ptr= 0;
}
2.2访问系统保护的内存地址
#include<stdio.h>
#include<stdlib.h>
void main()
{
int*ptr=(int*)0;
*ptr= 100;
}
2.3访问只读的内存地址
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
void main()
{
char*ptr="test";
strcpy(ptr,"TEST");
}
2.4栈溢出
#include<stdio.h>
#include<stdlib.h>
void main()
{
main();
}
等等其他原因。
3.段错误信息的获取
程序发生段错误时，提示信息很少，下面有几种查看段错误的发生信息的途径。
3.1 dmesg
dmesg可以在应用程序crash掉时，显示内核中保存的相关信息。如下所示，通过dmesg命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。以程序2.3为例：
panfeng@ubuntu:~/segfault$ dmesg
[ 2329.479037] segfault3[2700]: segfault at 80484e0 ip 00d2906a sp bfbbec3c error 7 in libc-2.10.1.so[cb4000+13e000]
3.2-g
使用gcc编译程序的源码时，加上-g参数，这样可以使得生成的二进制文件中加入可以用于gdb调试的有用信息。以程序2.3为例：
panfeng@ubuntu:~/segfault$ gcc-g-o segfault3 segfault3.c
3.3 nm
使用nm命令列出二进制文件中的符号表，包括符号地址、符号类型、符号名等，这样可以帮助定位在哪里发生了段错误。以程序2.3为例：
panfeng@ubuntu:~/segfault$ nm segfault3
08049f20 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
080484dc R _IO_stdin_used
w _Jv_RegisterClasses
08049f10 d __CTOR_END__
08049f0c d __CTOR_LIST__
08049f18 D __DTOR_END__
08049f14 d __DTOR_LIST__
080484ec r __FRAME_END__
08049f1c d __JCR_END__
08049f1c d __JCR_LIST__
0804a014 A __bss_start
0804a00c D __data_start
08048490 t __do_global_ctors_aux
08048360 t __do_global_dtors_aux
0804a010 D __dso_handle
w __gmon_start__
0804848a T __i686.get_pc_thunk.bx
08049f0c d __init_array_end
08049f0c d __init_array_start
08048420 T __libc_csu_fini
08048430 T __libc_csu_init
U __libc_start_main@@GLIBC_2.0
0804a014 A _edata
0804a01c A _end
080484bc T _fini
080484d8 R _fp_hw
080482bc T _init
08048330 T _start
0804a014 b completed.6990
0804a00c W data_start
0804a018 b dtor_idx.6992
080483c0 t frame_dummy
080483e4 T main
U memcpy@@GLIBC_2.0
3.4 ldd
使用ldd命令查看二进制程序的共享链接库依赖，包括库的名称、起始地址，这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。以程序2.3为例：
panfeng@ubuntu:~/segfault$ ldd./segfault3
linux-gate.so.1=>(0x00e08000)
libc.so.6=>/lib/tls/i686/cmov/libc.so.6(0x00675000)
/lib/ld-linux.so.2(0x00482000)
求助,VCS在ubuntu 64位的问题
您好，我在别的网站看到你的具体问题了，
解决方法如下：
执行编译命令，遇到这个问题后，在当前目录下会有一个csrc目录，进入这个目录，发现有个Makefile，用gedit打开，将下面字段
# Override TARGET_ARCH
TARGET_ARCH=
修改为：
# Override TARGET_ARCH
TARGET_ARCH=x86-64
并且删除*.o，rm*.o，然后再执行make，重新生成rmapats.o文件，这次生成的就对了。。。
这也是一种临时解决办法，真是折腾啊。。。
使用vcs-full64 x.v仍然存在问题，采用类似方法会出现段错误，64位使用不了。只能使用32位的了。
glibc 更新导致的段错误排查
在PAT练习中，姥姥遇到一个原本能通过的C程序，在两个测试点上出现了段错误。问题似乎与数据量有关，不在沙盒环境下运行正常，但沙盒中则出现segmentation fault。通过开放系统调用权限，程序在沙盒内能正常运行，最终发现是sysinfo系统调用被沙盒限制导致的错误。进一步验证显示，大数据集下qsort调用sysinfo，而后者在glibc中被设计用来提高性能。这一问题源于今年4月judger镜像升级至ubuntu 16.04，新版代码不再过滤sysinfo调用。具体到代码，当数组大小小于1024时，qsort会利用栈，否则会涉及sysinfo获取内存信息。
在sysinfo的使用上，glibc原本通过文件读取/proc/meminfo获取内存信息，但sysinfo提供的信息更全面且性能更高。对于大规模数组操作，如git测试集，这会导致额外的性能成本。通过gdb的syscall捕获功能，我们定位到msort.c#164的代码，进一步揭示了问题的触发点。
总结，问题的根源在于glibc更新后的sysinfo系统调用在大数据处理时被启用，而在旧版本的judger镜像中被限制，导致了段错误。随着镜像升级，这个问题已经得到解决，现在的judger不再过滤sysinfo调用。
