问题描述
这是一个大项目，实际上是我自定义设计的虚拟机.
This is a big project, actually a virtual machine of my custom design.
在某些情况下，每次我自己运行程序时，程序都会因分段错误而崩溃，但是在相同的情况下，它在GDB中运行却不会崩溃！
Under certain circumstances, program crashes with a segmentation fault every time when I run it on its own, but within GDB under those same circumstances it runs perfectly and never crashes!
在GDB内部和外部运行时，我会给它完全相同的参数和输入.
I am giving it the exact same parameters and input when running inside and outside GDB.
所以基本上，我找不到GDB的错误，因为使用我的GDB从来没有任何问题.
So basically, I can't find the bug with GDB because it never has any problem when I use GDB.
二进制文件已使用gcc -g选项进行编译.
The binary has been compiled with gcc -g option.
当我调用
$ gdb ./main ./memdump
$ gdb ./main ./memdump
(其中main是已编译的程序二进制文件)
(where main is the complied program binary)
并给bt命令，我得到没有堆栈".我读到这意味着堆栈已被完全破坏吗?
and give the bt command, I get "no stack". I read this means that the stack has been completely destroyed?
可能是什么原因造成的，我该如何实际找到该错误?
What could be causing this and how can I actually find the bug?
指令日志的最后几行
此输出显示在屏幕上，我将其重定向到文件.
This output prints on screen, I redirected it to a file.
cmp at address 313
je at address 314
jmp at address 316
inc at address 306
div at address 307
mult at address 308
sub at address 309
cmp at address 310
ecall at ad
每次都会在随机位置崩溃，通常无法完成printf()调用，如您在此处看到的.这是什么意思?
It crashes at a random place each time, and usually fails to finish the printf() call, as you can see here. What does this mean?
对不起，我实际上有错误的核心转储文件.
I'm sorry, I actually had the wrong core dump file.
现在我有合适的一个...核心回溯显示:
Now I have the right one...Core backtrace shows:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000040414e in int_call_internal_f (arg=14) at
./opcode_func.c:1503
1503 if (memory[int_config[0] + memory[ip + 1]] !=
INTERRUPT_BLOCKING_VALUE)
(gdb)
这毫无意义，因为它们都是全局变量，并且在这些索引的值最后一次更改之后，该行执行了数千次.
This makes no sense because these are all globals and this line executes thousands of times after the values at those indices last change.
推荐答案
通常，调试C程序意味着将局部变量(和其他内存)初始化为某种众所周知的模式.在释放模式下运行时，您的内存在分配时将具有任何位.
Generally, debugging C programs means that local variables (and other memory) are initialized to some well known pattern. When running in release mode, your memory will have whatever bits where there when allocated.
另一个难题是优化.如果您有并发性错误，则在调试器中运行将更改时间，从而使事情变得晦涩.优化还可以巧妙地更改事物的布局，以使在释放模式下爆炸的指针错误(尤其是偏移)无害地覆盖了调试模式下未使用的字节(反之亦然).
The other gotcha is optimizations. If you have a concurrency bug, running in the debugger will change the timing, obscuring things. Optimizations can also change the layout of things subtly so that pointer errors (offsets in particular) that blow up in release mode harmlessly overwrite unused bytes in debug mode (or vice versa).
这篇关于C程序可在GDB中运行，单独运行时会崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！