Question

虽然我的C程序看起来很完美但我得到了分段错误！以下是它的工作原理：

假设我们有一个包含6个int和1个int *的struct Heap。（大小为32字节）

struct Heap
{
  int* a;
  int  b;
  int  c;
  int  d; 
  int  e;
  bool f; // Trust me it's int
  bool g; // Trust me it's int
};

在 main（）中，我致电：

examine(heap, enable_cloning);

examine（）的作用是：

...
    if(!enable_cloning)
    {
        Heap* my_clone = new_Heap_from_clone(heap); // A clone is being made ...
...

现在让我们跳到棘手的部分（在 new_Heap_from_clone（）里面

Heap* new_Heap_from_clone(Heap const* the_original_or_clone_heap)
{
    Heap* heap = malloc(sizeof(Heap));
    if(heap == NULL)
        return NULL;

    memcpy(heap, the_original_or_clone_heap, sizeof(Heap)); //Happy Segmentation Fault !!!
    ...

运行GDB我得到：

(gdb) step
174     memcpy(heap, the_original_or_clone_heap, sizeof(the_original_or_clone_heap));
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x0000555555554dae in new_Heap_from_clone (the_original_or_clone_heap=0xb) at ./Heap.c:174
174     memcpy(heap, the_original_or_clone_heap, sizeof(the_original_or_clone_heap));
(gdb) sizeof *heap
Undefined command: "sizeof".  Try "help".
(gdb) print sizeof *heap
$5 = 32
(gdb) print sizeof *the_original_or_clone_heap
$6 = 32

注意： 我包含 memcpy（）的大小，以便我从您那里获得更多宝贵信息！ 让我们看看valgrind对此有何看法：

==6244== Use of uninitialised value of size 8
==6244==    at 0x108DAE: new_Heap_from_clone (Heap.c:174)
==6244==    by 0x1095ED: heapSort (Heap.c:481)
==6244==    by 0x10915F: sort (Heap.c:330)
==6244==    by 0x10A897: ds_bench (main.c:90)
==6244==    by 0x10A9B4: main (main.c:106)
==6244== 
==6244== Invalid read of size 8
==6244==    at 0x108DAE: new_Heap_from_clone (Heap.c:174)
==6244==    by 0x1095ED: heapSort (Heap.c:481)
==6244==    by 0x10915F: sort (Heap.c:330)
==6244==    by 0x10A897: ds_bench (main.c:90)
==6244==    by 0x10A9B4: main (main.c:106)
==6244==  Address 0xb is not stack'd, malloc'd or (recently) free'd
==6244== 
==6244== 
==6244== Process terminating with default action of signal 11 (SIGSEGV)
==6244==  Access not within mapped region at address 0xB
==6244==    at 0x108DAE: new_Heap_from_clone (Heap.c:174)
==6244==    by 0x1095ED: heapSort (Heap.c:481)
==6244==    by 0x10915F: sort (Heap.c:330)
==6244==    by 0x10A897: ds_bench (main.c:90)
==6244==    by 0x10A9B4: main (main.c:106)
==6244==  If you believe this happened as a result of a stack
==6244==  overflow in your program's main thread (unlikely but
==6244==  possible), you can try to increase the size of the
==6244==  main thread stack using the --main-stacksize= flag.
==6244==  The main thread stack size used in this run was 12001280.
==6244== 
==6244== HEAP SUMMARY:
==6244==     in use at exit: 1,648 bytes in 31 blocks
==6244==   total heap usage: 32 allocs, 1 frees, 2,672 bytes allocated
==6244== 
==6244== LEAK SUMMARY:
==6244==    definitely lost: 0 bytes in 0 blocks
==6244==    indirectly lost: 0 bytes in 0 blocks
==6244==      possibly lost: 0 bytes in 0 blocks
==6244==    still reachable: 1,648 bytes in 31 blocks
==6244==         suppressed: 0 bytes in 0 blocks
==6244== Reachable blocks (those to which a pointer was found) are not shown.
==6244== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6244== 
==6244== For counts of detected and suppressed errors, rerun with: -v
==6244== Use --track-origins=yes to see where uninitialised values come from
==6244== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

请记住，我以前没有valgrind的经验，但它显而易见：

== 6244 ==不在地址0xB的映射区域内访问

但我认为不存在这样的问题...... 是否有可能以某种方式运行堆栈空间？但是，在这种情况下，运行valgrind：

valgrind --leak-check = yes --main-stacksize=12000000 ./hxn 这超过了它的默认值（8388608）并得到了你所看到的相同答案。

那么地球上的东西是什么？

Answer 1

您将未初始化的指针传递给new_Heap_from_clone()。 gdb和valgrind都试图告诉你：

gdb告诉你指针是0xb，这是gdb中未初始化指针的经典值;和
当valgrind说Use of uninitialised value of size 8时，它不会更明显。

这会通过检查，因为0xb不为空; 0x0是。因此，当您致电new_Heap_from_clone(heap)时，您不应该使用值heap初始化该特定null。

使用gdb的回溯功能（up进入调用堆栈，down向下移动）以找出出错的确切位置。

memcpy导致奇怪的分段错误

1 个答案: