Leetcode报错AddressSanitizer: heap-buffer-overflow on address 0x603000000028

本文解析了LeetCode 136题目只出现一次的数字的解题思路,通过分析给出的C代码,发现了数组访问越界的bug并进行了修复。文章强调了正确的代码逻辑和内存安全的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  • 1.我们先看代码,贴出来


int singleNumber(int* nums, int numsSize){
    int i = 1;
    int data;
    
    data = nums[0];
    while (i < numsSize) {
        if (data != nums[i]) {
            i++;
        }
        else {
            i += 2;
            data = nums[i+1];
        }
    }
    return data;
}

 

  • 2.题目描述 :leetcode 136 只出现一次的数字

给定一个非空整数数组,除了某个元素只出现一次以外,其余每个元素均出现两次。找出那个只出现了一次的元素。

说明:

你的算法应该具有线性时间复杂度。 你可以不使用额外空间来实现吗?

示例 1:

输入: [2,2,1]
输出: 1

示例 2:

输入: [4,1,2,1,2]
输出: 4

 

  • 3.错误信息

代码报了一长串的错误,奇怪的是,在用VSCode环境debug时,并未报错。搜索问题发现,LeetCode 使用了AddressSanitizer检查是否存在内存非法访问,该问题检查内存非法访问问题,发现问题出在这里

else {

            i += 2;

            data = nums[i+1];

        }

 

在data赋值前先进行i+2操作,再执行num[i+1]时既有可能引起i大于size值,使得数组nums[]访问越界,修改后执行ok

 else {

            data = nums[i+1];

             i += 2;

        }

 

  • 4.附上报错信息
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000028 at pc 0x0000004018d1 bp 0x7ffc7efb9960 sp 0x7ffc7efb9958

READ of size 4 at 0x603000000028 thread T0

    #2 0x7f54691a52e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)



0x603000000028 is located 4 bytes to the right of 20-byte region [0x603000000010,0x603000000024)

allocated by thread T0 here:

    #0 0x7f546a62f2b0 in malloc (/usr/local/lib64/libasan.so.5+0xe82b0)

    #3 0x7f54691a52e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)



Shadow bytes around the buggy address:

  0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

=>0x0c067fff8000: fa fa 00 00 04[fa]fa fa fa fa fa fa fa fa fa fa

  0x0c067fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

Shadow byte legend (one shadow byte represents 8 application bytes):

  Addressable:           00

  Partially addressable: 01 02 03 04 05 06 07

  Heap left redzone:       fa

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack after return:      f5

  Stack use after scope:   f8

  Global redzone:          f9

  Global init order:       f6

  Poisoned by user:        f7

  Container overflow:      fc

  Array cookie:            ac

  Intra object redzone:    bb

  ASan internal:           fe

  Left alloca redzone:     ca

  Right alloca redzone:    cb

==30==ABORTIN

 

<think>嗯,用户遇到了AddressSanitizer报告的heap-buffer-overflow错误,地址是0x503000000058,程序计数器是0x55a2626762ad。我需要先理解这个错误的原因,然后给出解决方案。 首先,AddressSanitizer检测到堆缓冲区溢出,这通常是因为程序访问了超出分配内存范围的地址。用户提到在LeetCode上遇到这个问题,特别是在处理单字符时使用memset出错,而双字符及以上没问题。这可能是因为在处理单字符时,某些边界条件没有处理好,比如数组长度计算错误,或者循环条件设置不当。 根据引用[2],溢出通常由数组或向量访问越界引起。例如,当分配的内存大小为n,但访问了n或更大的索引时。例如,访问array[n]就会越界,因为有效索引是0到n-1。用户需要检查代码中的数组访问,特别是循环的终止条件是否正确。 引用[4]提到,常见原因之一是调用超出数组长度的索引元素。比如,在循环中是否错误地使用了<=而不是<,或者在处理字符串时未正确处理结束符'\0'的位置。例如,当字符串长度为1时,比如s="a",strlen(s)返回1,但有效的字符索引是0,如果在循环中错误地访问了索引1,就会导致越界。 用户提供的示例中,当s是单字符时,使用memset出错。可能是在分配内存时分配了不足的空间,或者在调用memset时传入了错误的大小参数。例如,如果为单字符分配了恰好1字节的内存,但memset试图写入超过1字节的数据,就会溢出。或者,可能在计算需要操作的内存大小时,没有考虑到某些边界情况,比如空字符或者对齐问题。 解决方案方面,需要逐步检查内存分配和访问的代码。首先,确认所有数组和缓冲区的分配大小是否正确,是否考虑了所有可能的边界情况。其次,检查循环和索引的使用,确保没有超出有效范围。可以使用调试工具或打印语句来跟踪索引的值,特别是在处理边界条件时。此外,将if-else结构改为更严谨的条件判断,避免多个条件语句之间的覆盖问题,如引用[3]中提到的将第二个if改为else,这样可以避免在条件判断中出现遗漏或重复的情况。 例如,在处理字符串时,如果有一个循环从0到strlen(s),那么当i等于strlen(s)时,s[i]就是越界访问,因为索引应该到strlen(s)-1。这种情况下,循环条件应该改为i < strlen(s)。或者在动态分配内存时,如果需要的空间是n+1(比如包含结束符),但只分配了n,就会导致溢出。 另外,用户提到在DevC++中代码运行正常,但在LeetCode报错,这可能是因为不同的编译器或环境对内存错误的处理方式不同。有些环境可能不会严格检查越界访问,而AddressSanitizer则会主动检测这类问题。因此,用户需要确保代码符合严格的内存管理规范,避免未定义行为。 总结来说,用户需要检查代码中的内存分配大小是否正确,所有数组访问是否在有效范围内,条件判断是否覆盖了所有边界情况,特别是单字符或空字符串的情况。同时,使用调试工具或打印日志来定位具体的越界位置,逐步修正错误。</think>关于AddressSanitizer检测到的`heap-buffer-overflow`问题的解决方案如下: --- ### **问题原因** 1. **内存越界访问**:程序尝试访问未分配的堆内存区域,例如: - 数组索引超出分配范围(如`array[n]`访问,但数组实际有效索引为`0`到`n-1`) - 字符串操作未正确处理结束符`\0`的位置 2. **边界条件处理不当**:例如单字符场景下未考虑最小长度限制,导致`memset`或循环操作越界[^1][^2] 3. **条件判断逻辑错误**:多个`if`语句可能覆盖不全或重复判断,导致意外越界[^3] --- ### **解决方案** #### 1. 检查内存分配与访问范围 - **验证内存分配长度**:确保分配的空间足够覆盖所有操作需求。例如: ```c char* buffer = malloc(strlen(s) + 1); // 为字符串结束符预留空间 ``` - **检查循环边界**:确保循环终止条件正确。例如: ```c for (int i = 0; i < len; i++) { ... } // 正确:i从0到len-1 ``` #### 2. 修正条件判断逻辑 - 避免多个`if`嵌套导致的逻辑漏洞,改用`if-else`结构: ```c if (condition1) { ... } else if (condition2) { ... } // 避免同时满足多个条件 ``` #### 3. 调试工具辅助定位 - **使用AddressSanitizer输出**:根据报错信息中的**错误地址**(如`0x503000000058`)和**程序计数器**(如`0x55a2626762ad`),结合反汇编工具或调试器定位具体代码位置。 - **打印调试日志**:在可疑代码段前后添加变量值输出,观察索引是否超出预期范围。 #### 4. 典型修复示例 假设报错由以下代码引起(错误代码): ```c void process_string(char* s) { int len = strlen(s); char* buffer = malloc(len); memset(buffer, 0, len + 1); // 错误:多写入1字节导致溢出 } ``` 修复方法: ```c void process_string(char* s) { int len = strlen(s); char* buffer = malloc(len + 1); // 正确分配空间 memset(buffer, 0, len + 1); // 合法操作 } ``` --- ### **预防措施** 1. **静态代码分析**:使用Clang静态分析器或Cppcheck扫描潜在越界风险 2. **单元测试覆盖边界条件**:例如空字符串、单字符、最大长度输入等场景 3. **代码规范**:优先使用安全函数(如`snprintf`替代`sprintf`) ---
评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值