精华内容
下载资源
问答
  • 内存踩踏解决

    千次阅读 2020-02-12 09:17:13
    上面文章写了内存踩踏的原因:由于malloc的heap内存占到了irq的stack,导致出现内存重叠。主要原因是用到了uc2的malloc函数,这个malloc是由c库来实现的,当malloc太大,heap区域的不够大的时候,malloc会向上增长...

    上面文章写了内存踩踏的原因:由于malloc的heap内存占到了irq的stack,导致出现内存重叠。主要原因是用到了uc2的malloc函数,这个malloc是由c库来实现的,当malloc太大,heap区域的不够大的时候,malloc会向上增长从而导致占用了heap的内存。

    解决方法就是增大heap的的大小:

    链接脚本中增大heap的大小:

     

    当然也可以应用ucos2自己实现的内存管理机制:应用内存池,进行分配。这样也可以减少内存碎片的发生。

    展开全文
  • Camera FaceHal内存踩踏问题解读

    千次阅读 2020-10-22 23:13:56
    什么是内存踩踏 访问了不合法的地址。通俗一点就是访问了不属于自己的地址。如果这块地址分配给了另一个变量使用,就会破坏别人的数据。从而导致程序运行异常,挂死,输出图像破图等。 二.内存踩踏可能情形 数组...

    一.什么是内存踩踏

    访问了不合法的地址 。通俗一点就是访问了不属于自己的地址。如果这块地址分配给了另一个变量使用,就会破坏别人的数据。从而导致程序运行异常,挂死,输出图像破图等

    二.内存踩踏可能情形

    1. 组访问越界;
    2. 字符串操作越界;
    3. 野指针;
    4. 重复释放;
    5. 指针类型转换错误;
    6. 栈溢出;
    7. 堆溢出
    8. 释放在使用;
    9. 多线程读写的数据没有保护;
    10. 多线程使用线程不安全的函数;
    11. 其他;

    三.如何排查

    1.查看ylog,帮助缩小排查范围;

    2.加入debug log,进一步缩小范围;打印相关内存地址/值;

    3.将被踩踏内存设置成只读,在调用栈中查看谁在写;

    4.链接排查内存踩踏的工具Asan来帮助排查;

    5.其他;

    四.如何避免

    1. 格遵守编程规范;
    2. 数组访问边界检查,数值传递需防止溢出;
    3. 申请内存/使用内存判空和释放内存需置空;
    4. 变量定义好后及时赋初值,特别像结构体这种;
    5. 多线程访问时做好线程保护;
    6. 其他;

    内存踩踏定位的成本很高,一旦出现严重的内存踩踏问题,排查的成本是很高很高的。

    FaceHal内存踩踏案例分析

    1.涉及bug

    问题1: 【K2】录入人脸后,打开活体检测后进行解锁,无法解锁

    问题2: 【K2】录入人脸后,未识别到人脸时或识别非录入脸,无提示语以及图标不跳动

    2.问题现象

    (1)K2平台 人脸解锁大概率失败,其他平台无此异常;

    (2)从log看各个平台都能通过tag将metadata.update(ANDROID_XXX_TO_FACEIDSERVICE_PHYADDR,&mUnlockPhyaddr, 1);

    将物理地址传递给FaceHal,FaceHal将物理地址&相关统计信息传递给FaceUnlock算法处理使用,当算法根据信息无法解锁时会将result状态置为AUTH_CONTINUE然后通过

    CameraHelper::getInstance()->freeAlgoBuffer(main_addr,sub_addr)接口去实现buffer的轮转。

    M008192  10-09 05:43:12.004   335  1533 D Cam3SingleFaceIdU: 1091, processCaptureResultMain: callback phy addr=0xbf6fc000
    M008193  10-09 05:43:12.004   335  1533 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf6fc000
    M008216  10-09 05:43:12.018   359  1507 D CameraHelper: onCameraResultAvailable: getConstEntry  entryAddrToFaceID bf6fc000.
    M008217  10-09 05:43:12.018   359  1507 D CameraHelper: onCameraResultAvailable: getConstEntry  resultAeState 2.
    M0082B7  10-09 05:43:12.032   359   511 I CameraHelper: AlgoHandler onMessageReceived ALGO_AUTH_REQUEST .
    M0082BA  10-09 05:43:12.032   359   511 D FaceIdHal: get_virtual_address result:0xad617000 , in_size:fd200 , real size:fe000 ,pagesize:1000
    M0082BB  10-09 05:43:12.032   359   511 D FaceIdHal: get_virtual_address input phy addr:bf6fc000
    M0082BC  10-09 05:43:12.032   359   511 D FaceIdHal: auth_proc_run help interact info, 0 - 0 -0 -0 -0 - 0 .
    M0082BD  10-09 05:43:12.033   359   511 I FaceID  : 485, getHelpInfo: aeStable: 0, backlightPro : 0, brightValue: 548, blEnable: 0, faceLum: 0
    M0082D1  10-09 05:43:12.033   359   511 I FaceID  : 247, getFaceShape: detect face num = 0
    M0082D3  10-09 05:43:12.046   359   511 D FaceIdHal: auth_proc_run single camera, ret is 1
    M0082D4  10-09 05:43:12.046   359   511 I FaceIdHal: auth_proc_run duration:1352 ms , max dura:8000 ms , end:41169726393 ,start:39817445240
    M0082D5  10-09 05:43:12.046   359   511 I FaceIdHal: face_do_authenticate_process(), result: 2
    M008323  10-09 05:43:12.052   359   511 I CameraHelper: freeAlgoBuffer set PhyAddrFromFaceID with main_addr: bf6fc000.

    现在较奇怪的现象是S1等平台通过该接口可以使Face buffer正常轮转,而K2的Face buffer无法正常轮转,ACaptureRequest_setEntry_i64&ACaptureRequest_setEntry_i32下设meta出现native framework 存在error信息:

    M008323  10-09 05:43:12.052   359   511 I CameraHelper: freeAlgoBuffer set PhyAddrFromFaceID with main_addr: bf6fc000.
    M008325  10-09 05:43:12.052   359   511 E CamComm1.0-VTDesc: getTagType: Vendor descriptor id is missing!
    M008327  10-09 05:43:12.052   359   511 E CamComm1.0-VTDesc: getTagName: Vendor descriptor id is missing!
    M008328  10-09 05:43:12.052   359   511 E CamComm1.0-MD: Mismatched tag type when updating entry (null) (-2147483583) of type byte; got type int64 data instead
    M0083D5  10-09 05:43:12.118   359   511 E CamComm1.0-VTDesc: getTagType: Vendor descriptor id is missing!
    M0083D7  10-09 05:43:12.118   359   511 E CamComm1.0-VTDesc: getTagName: Vendor descriptor id is missing!
    M0083D8  10-09 05:43:12.118   359   511 E CamComm1.0-MD: Mismatched tag type when updating entry (null) (-2147483597) of type byte; got type int32 data instead
    M0083FF  10-09 05:43:12.122   538  1555 E camera_metadata: validate_camera_metadata_structure: Entry index 0 had 0 items, but offset was non-0 (196608), tag name: mode
    M008400  10-09 05:43:12.122   538  1555 E cameraserver: convertFromHidl: Malformed camera metadata received from HAL
    M008401  10-09 05:43:12.122   538  1555 E cameraserver: copyPhysicalCameraSettings: Unable to convert physicalCameraSettings from HIDL to AIDL.

    从报错信息看似乎与Tag找不到id信息有关,导致后续camera metadata在check type时出现Mismatched错误,似乎从信息看此时Tag PhyAddrFromFaceID对应的数据变成了byte而不是规定的int64,另外一个tag sprd3DeviceOrientation对应的数据也是变成了byte而不是规定的int32。

    于是怀疑传递给native framework层的tag出现问题导致后续一连串的错误,因此对FaceHal与cam_Hal之间tag的对应关系进行加log打印:

    M008321  10-09 05:43:12.052   359   511 I CameraHelper: freeAlgoBuffer get PhyAddrFromFaceID status : 0 , namedTag: -2147483583.
    M008323  10-09 05:43:12.052   359   511 I CameraHelper: freeAlgoBuffer set PhyAddrFromFaceID with main_addr: bf6fc000.
    M0083CA  10-09 05:43:12.107   359   511 I CameraHelper: freeAlgoBuffer get DeviceOrientation status : 0 , namedTag: -2147483597.
    M0083D0  10-09 05:43:12.108   359   511 I CameraHelper: freeAlgoBuffer set DeviceOrientation with : 180.
    M00844B  10-09 05:43:12.131   335   335 D Cam3SingleFaceIdU: 964, processCaptureRequest: From -2147483583
    M00844B  10-09 05:43:12.131   335   335 D Cam3SingleFaceIdU: 965, processCaptureRequest:  Orientation  -2147483597

    从打印log看FaceHal与cam_Hal 对应tag name之间的关系可以匹配上,FaceHal第一个接口ACameraManager_getTagFromName应该不存在问题。对“ CamComm1.0-VTDesc”getTagName&getTagType添加tag&id的log打印信息,其静态库“android.hardware.camera.common@1.0-helper”编译其关联动态库可l令使其生效“libcamera2ndk_vendor.so”,K2和S1打印情况如下:

    >>K2 vendor id打印

    M008318  10-09 05:43:12.051   359   511 I CamComm1.0-VTDesc: tag -2147483581 id-440459957
    M008319  10-09 05:43:12.051   359   511 I CamComm1.0-VTDesc: tag -2147483582 id-440459957
    M008321  10-09 05:43:12.052   359   511 I CameraHelper: freeAlgoBuffer get PhyAddrFromFaceID status : 0 , namedTag: -2147483583.
    M008323  10-09 05:43:12.052   359   511 I CameraHelper: freeAlgoBuffer set PhyAddrFromFaceID with main_addr: bf6fc000.
    M008324  10-09 05:43:12.052   359   511 I CamComm1.0-VTDesc: tag -2147483583 id1
    M008325  10-09 05:43:12.052   359   511 E CamComm1.0-VTDesc: getTagType: Vendor descriptor id is missing!
    M008326  10-09 05:43:12.052   359   511 I CamComm1.0-VTDesc: tag -2147483583 id1
    M008327  10-09 05:43:12.052   359   511 E CamComm1.0-VTDesc: getTagName: Vendor descriptor id is missing!
    M008328  10-09 05:43:12.052   359   511 E CamComm1.0-MD: Mismatched tag type when updating entry (null) (-2147483583) of type byte; got type int64 data instead
    M0083CA  10-09 05:43:12.107   359   511 I CameraHelper: freeAlgoBuffer get DeviceOrientation status : 0 , namedTag: -2147483597.
    M0083D0  10-09 05:43:12.108   359   511 I CameraHelper: freeAlgoBuffer set DeviceOrientation with : 180.
    M0083D4  10-09 05:43:12.117   359   511 I CamComm1.0-VTDesc: tag -2147483597 id1
    M0083D5  10-09 05:43:12.118   359   511 E CamComm1.0-VTDesc: getTagType: Vendor descriptor id is missing!
    M0083D6  10-09 05:43:12.118   359   511 I CamComm1.0-VTDesc: tag -2147483597 id1
    M0083D7  10-09 05:43:12.118   359   511 E CamComm1.0-VTDesc: getTagName: Vendor descriptor id is missing!
    M0083D8  10-09 05:43:12.118   359   511 E CamComm1.0-MD: Mismatched tag type when updating entry (null) (-2147483597) of type byte; got type int32 data instead
    M0083FF  10-09 05:43:12.122   538  1555 E camera_metadata: validate_camera_metadata_structure: Entry index 0 had 0 items, but offset was non-0 (196608), tag name: mode
    M008400  10-09 05:43:12.122   538  1555 E cameraserver: convertFromHidl: Malformed camera metadata received from HAL
    M008401  10-09 05:43:12.122   538  1555 E cameraserver: copyPhysicalCameraSettings: Unable to convert physicalCameraSettings from HIDL to AIDL.
    M008406  10-09 05:43:12.122   359   511 I CameraHelper: ACameraCaptureSession_capture ret: -10001, seqId=0

    >>S1 vendor id打印

    M00945C  10-11 14:31:43.988   367   520 I CamComm1.0-VTDesc: tag -2147483581 id-440459957
    M00945E  10-11 14:31:43.988   367   520 I CameraHelper: freeAlgoBuffer get PhyAddrFromFaceID status : 0 , namedTag: -2147483583.
    M00945F  10-11 14:31:43.988   367   520 I CameraHelper: freeAlgoBuffer set PhyAddrFromFaceID with main_addr: bfa80000.
    M009460  10-11 14:31:43.988   367   520 I CamComm1.0-VTDesc: tag -2147483583 id-440459957
    M009462  10-11 14:31:43.988   367   520 I CamComm1.0-VTDesc: tag -2147483583 id-440459957

    从对比log可以很明显的看出,K2的 getTagType& getTagName传递进去的tag name是不存在问题的,只是vendor id出现了异常导致K2的meta的map索引出现异常。查看FaceHal更新meta的接口:

    ACaptureRequest_setEntry_i64(mPreviewRequest, namedTag, /*count*/ 1, &main_addr);从接口可以看出第一个参数为Request,第二个参数为需要更新的tag name,第三个参数为数量,第四个为tag data.很显然出现问题的是第一个参数,因只有它包含meta信息。跟踪该参数的使用过程:

    1)创建request:

    // Create capture request
    ret = ACameraDevice_createCaptureRequest(mDevice,TEMPLATE_PREVIEW, &mPreviewRequest);
    调到native framework层return device->createCaptureRequest(templateId, nullptr /*physicalIdList*/, request);
    调到frameworks/av/camera/ndk/ndk_vendor/impl/AcameraDevice.cpp
    139  camera_status_t
    140  CameraDevice::createCaptureRequest(
    141          ACameraDevice_request_template templateId,
    142          const ACameraIdList* physicalCameraIdList,
    143          ACaptureRequest** request) const {
    144      Mutex::Autolock _l(mDeviceLock);
    145      camera_status_t ret = checkCameraClosedOrErrorLocked();
    146      if (ret != ACAMERA_OK) {
    147          return ret;
    148      }
    149      if (mRemote == nullptr) {
    150          return ACAMERA_ERROR_CAMERA_DISCONNECTED;
    151      }
    152      CameraMetadata rawRequest;
    153      Status status = Status::UNKNOWN_ERROR;
    154      auto remoteRet = mRemote->createDefaultRequest(
    155          utils::convertToHidl(templateId),
    156          [&status, &rawRequest](auto s, const hidl_vec<uint8_t> &metadata) {
    157              status = s;
    158              if (status == Status::NO_ERROR && utils::convertFromHidlCloned(metadata, &rawRequest)) {
    159              } else {
    160                  ALOGE("%s: Couldn't create default request", __FUNCTION__);
    161              }
    162          });
    163      CHECK_TRANSACTION_AND_RET(remoteRet, status, "createDefaultRequest()")
    164      ACaptureRequest* outReq = new ACaptureRequest();
    165      outReq->settings = new ACameraMetadata(rawRequest.release(), ACameraMetadata::ACM_REQUEST);
    166      if (physicalCameraIdList != nullptr) {
    167          for (auto i = 0; i < physicalCameraIdList->numCameras; i++) {
    168              outReq->physicalSettings.emplace(physicalCameraIdList->cameraIds[i],
    169                      new ACameraMetadata(*(outReq->settings)));
    170          }
    171      }
    172      outReq->targets  = new ACameraOutputTargets();
    173      *request = outReq;
    174      return ACAMERA_OK;
    175  }

    165行>>这里创建了setting,打印出3层metadata内容

    request 0xb64b7380,   

    settings 0xb65c4f00,    <<—— ACameraMetadata

    data 0xb670b70c,         <<—— CameraMetadata

    __data 0xb63bb000     <<——  camera_metadata_t

     2)更新setting

    frameworks/av/camera/ndk/NdkCaptureRequest.cpp 

    135  camera_status_t ACaptureRequest_setEntry_##NAME(                                        
    136          ACaptureRequest* req, uint32_t tag, uint32_t count, const NDK_TYPE* data) {     
    137      ATRACE_CALL();                                                                      
    138      if (req == nullptr || (count > 0 && data == nullptr)) {                             
    139          ALOGE("%s: invalid argument! req %p, tag 0x%x, count %d, data 0x%p",            
    140                 __FUNCTION__, req, tag, count, data);                                    
    141          return ACAMERA_ERROR_INVALID_PARAMETER;                                         
    142      }                                                                                   
    143      return req->settings->update(tag, count, data);                                     
    144  } 

    143行>>这里更新PhyAddrFromFaceID地址,对应face hal中

    查看mPreviewRequest  meta结构:

    struct ACaptureRequest {
        camera_status_t setContext(void* ctx) {
            context = ctx;
            return ACAMERA_OK;
        }
        camera_status_t getContext(void** ctx) const {
            *ctx = context;
            return ACAMERA_OK;
        }
        sp<ACameraMetadata> settings;
        std::unordered_map<std::string, sp<ACameraMetadata>> physicalSettings;
        ACameraOutputTargets* targets;
        void*                 context;
    };
    struct ACameraMetadata : public RefBase {
    …......................
        camera_status_t updateImpl(uint32_t tag, uint32_t count, const NDK_T* data) {
          …......................
            status_t ret = OK;
            if (count == 0 && data == nullptr) {
                ret = mData->erase(tag);
            } else {
                // Here we have to use reinterpret_cast because the NDK data type is
                // exact copy of internal data type but they do not inherit from each other
                ret = mData->update(tag, reinterpret_cast<const INTERNAL_T*>(data), count);
            }  //上述update的具体实现
    ….........................
        std::shared_ptr<CameraMetadata> mData;
    …..................................
    };
    status_t CameraMetadata::update(uint32_t tag,
            const int64_t *data, size_t data_count) {
        status_t res;
        if (mLocked) {
            ALOGE("%s: CameraMetadata is locked", __FUNCTION__);
            return INVALID_OPERATION;
        }
        if ( (res = checkType(tag, TYPE_INT64)) != OK) {
            return res;
        }
        return updateImpl(tag, (const void*)data, data_count);
    }
    如果tag type不匹配,会打印“Mismatched xxx”的log,和两次vendor id失败的log
    const char* VendorTagDescriptorCache::getTagName(uint32_t tag, metadata_vendor_id_t id) const {
        const char* ret = nullptr;
        auto desc = mVendorMap.find(id);
        if (desc != mVendorMap.end()) {
            ret = desc->second->getTagName(tag);
        } else {
            ALOGE("%s: Vendor descriptor id is missing!", __func__);
        }
        return ret;
    }
    int VendorTagDescriptorCache::getTagType(uint32_t tag, metadata_vendor_id_t id) const {
        int ret = 0;
        auto desc = mVendorMap.find(id);
        if (desc != mVendorMap.end()) {
            ret = desc->second->getTagType(tag);
        } else {
            ALOGE("%s: Vendor descriptor id is missing!", __func__);
        }
        return ret;
    }
    在VendorTagDescriptorCache中通过vendor id寻找descriptor,但由于id不正确无法找到,输出这句log
    class CameraMetadata: public Parcelable {
    …...............................
     camera_metadata_t *mBuffer; //在update失败时发现该指针已经已经变化,需要进一步排查
    }
    typedef struct camera_metadata camera_metadata_t;
    struct camera_metadata {
        metadata_size_t          size;
        uint32_t                 version;
        uint32_t                 flags;
        metadata_size_t          entry_count;
        metadata_size_t          entry_capacity;
        metadata_uptrdiff_t      entries_start; // Offset from camera_metadata
        metadata_size_t          data_count;
        metadata_size_t          data_capacity;
        metadata_uptrdiff_t      data_start; // Offset from camera_metadata
        uint32_t                 padding;    // padding to 8 bytes boundary
        metadata_vendor_id_t     vendor_id;
    };

    request 0xb64b7380,

    settings 0xb65c4f00,    <<——  ACameraMetadata

    data 0xb670b70c,       <<—— CameraMetadata

    __data 0xb652c600,   <<—— camera_metadata_t

    对比1)&2)地址,可以看出

    这里面同样的CameraMetada(0xb670b70c),封装的camera_metadata_t已经变了(0xb63bb000 -> 0xb652c600)

    打印meta地址发现以改变,怀疑内存踩踏meta导致K2无法规范buffer,通过将FaceHal链接的Face算法库进行bypass方式测试,问题仍存在,排除算法模块内存踩踏。后续将camera某块链接asan未发现问题,又通过对FaceHal链接内存踩踏debug工具Asan,FaceID模块增加asan工具方法如下:
    1)可执行文件vendor.xxx.hardware.face@1.0-service链接asan
    diff --git a/1.0/default/Android.bp b/1.0/default/Android.bp
    index bcde4d4..ba41c30 100644
    --- a/1.0/default/Android.bp
    +++ b/1.0/default/Android.bp
    @@ -21,6 +21,7 @@ cc_binary {
         ],
         sanitize: {
             cfi: true,
    +        address: true,
             diag: {
                 cfi: true,
             },
    2)FaceHAL  face.default.so链接asan
    diff --git a/Android.mk b/Android.mk
    index 36a721b..1552f97 100644
    --- a/Android.mk
    +++ b/Android.mk
    @@ -42,6 +42,7 @@ endif
     LOCAL_CFLAGS += -Wall -Wextra
     LOCAL_MODULE_TAGS := optional
    +LOCAL_SANITIZE := address
     ...................
     LOCAL_MODULE_TAGS := optional
    +LOCAL_SANITIZE := address

    打印出FaceHal出现栈溢出heap-buffer-overflow,crash问题log如下:

    C014A8B  10-09 22:13:18.951  2594  2930 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 2930 (C2N-dev-looper), pid 2594 (face@1.0-servic)
    C014B6F  10-09 22:13:19.117  2978  2978 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    C014B70  10-09 22:13:19.118  2978  2978 F DEBUG   : Native Crash TIME: 363240
    C014B73  10-09 22:13:19.118  2978  2978 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    C014B74  10-09 22:13:19.118  2978  2978 F DEBUG   : Build fingerprint: 'XXXXXXXXXXXXXXXXXXXXXXXXX:11/RP1A.201005.001/41547:userdebug/test-keys'
    C014B75  10-09 22:13:19.118  2978  2978 F DEBUG   : Revision: '0'
    C014B76  10-09 22:13:19.118  2978  2978 F DEBUG   : ABI: 'arm'
    C014B77  10-09 22:13:19.123  2978  2978 F DEBUG   : Timestamp: 2020-10-09 22:13:19+0800
    C014B78  10-09 22:13:19.123  2978  2978 F DEBUG   : pid: 2594, tid: 2930, name: C2N-dev-looper  >>> /vendor/bin/hw/vendor.xxx.hardware.face@1.0-service <<<
    C014B79  10-09 22:13:19.124  2978  2978 F DEBUG   : uid: 1000
    C014B7A  10-09 22:13:19.124  2978  2978 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : Abort message: '=================================================================
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : ==2594==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x89c02f28 at pc 0xa55f0504 bp 0x8a0fbe38 sp 0x8a0fbe34
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : WRITE of size 4 at 0x89c02f28 thread T13 (C2N-dev-looper)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #0 0xa55f0500  (/vendor/lib/hw/face.default.so+0x1b500)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #1 0xa9f9497e  (/vendor/lib/libcamera2ndk_vendor.so+0x1197e)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #2 0xabda134e  (/apex/com.android.vndk.v30/lib/libstagefright_foundation.so+0xf34e)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #3 0xabda38f6  (/apex/com.android.vndk.v30/lib/libstagefright_foundation.so+0x118f6)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #4 0xabda1afa  (/apex/com.android.vndk.v30/lib/libstagefright_foundation.so+0xfafa)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #5 0xac3abdce  (/apex/com.android.vndk.v30/lib/libutils.so+0xedce)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #6 0xac3ab886  (/apex/com.android.vndk.v30/lib/libutils.so+0xe886)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #7 0xac26a070  (/system/lib/libclang_rt.asan-arm-android.so+0x8a070)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #8 0xabf5cefc  (/apex/com.android.runtime/lib/bionic/libc.so+0xaaefc)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #9 0xabf15bfa  (/apex/com.android.runtime/lib/bionic/libc.so+0x63bfa)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : 
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : 0x89c02f28 is located 0 bytes to the right of 1704-byte region [0x89c02880,0x89c02f28)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : allocated by thread T2 (FaceRequestLoop) here:
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #0 0xac27fe2c  (/system/lib/libclang_rt.asan-arm-android.so+0x9fe2c)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #1 0xa55eedf4  (/vendor/lib/hw/face.default.so+0x19df4)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #2 0xa55ee504  (/vendor/lib/hw/face.default.so+0x19504)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #3 0xa55dfdf0  (/vendor/lib/hw/face.default.so+0xadf0)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #4 0x7e4b840  (/vendor/bin/hw/vendor.xxx.hardware.face@1.0-service+0x4840)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #5 0xa481a47c  ([anon:SizeClassAllocator]+0x1a47c)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : 
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : Thread T13 (C2N-dev-looper) created by T2 (FaceRequestLoop) here:
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #0 0xac269f24  (/system/lib/libclang_rt.asan-arm-android.so+0x89f24)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #1 0xac3ab720  (/apex/com.android.vndk.v30/lib/libutils.so+0xe720)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : 
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : Thread T2 (FaceRequestLoop) created by T0 here:
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #0 0xac269f24  (/system/lib/libclang_rt.asan-arm-android.so+0x89f24)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :     #1 0xac3ab720  (/apex/com.android.vndk.v30/lib/libutils.so+0xe720)
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : 
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : SUMMARY: AddressSanitizer: heap-buffer-overflow (/vendor/lib/hw/face.default.so+0x1b500) 
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : Shadow bytes around the buggy address:
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf28590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf285a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf285b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf285c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf285d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : =>0x9cf285e0: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf285f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf28600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf28610: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf28620: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   0x9cf28630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : Shadow byte legend (one shadow byte represents 8 application bytes):
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Addressable:           00
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Partially addressable: 01 02 03 04 05 06 07 
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Heap left redzone:       fa
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Freed heap region:       fd
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Stack left redzone:      f1
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Stack mid redzone:       f2
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Stack right redzone:     f3
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Stack after return:      f5
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Stack use after scope:   f8
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Global redzone:          f9
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Global init order:       f6
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Poisoned by user:        f7
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Container overflow:      fc
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Array cookie:            ac
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Intra object redzone:    bb
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   ASan internal:           fe
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Left alloca redzone:     ca
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Right alloca redzone:    cb
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   :   Shadow gap:              cc
    C014B7B  10-09 22:13:19.124  2978  2978 F DEBUG   : '
    C014B7C  10-09 22:13:19.124  2978  2978 F DEBUG   :     r0  00000000  r1  00000b72  r2  00000006  r3  8a0fb2d0
    C014B8D  10-09 22:13:19.147  2978  2978 F DEBUG   :     r4  8a0fb2e4  r5  8a0fb2c8  r6  00000a22  r7  0000016b
    C014B8E  10-09 22:13:19.147  2978  2978 F DEBUG   :     r8  8a0fb2d0  r9  8a0fb2e0  r10 8a0fb300  r11 8a0fb2f0
    C014B8F  10-09 22:13:19.147  2978  2978 F DEBUG   :     ip  00000b72  sp  8a0fb2a0  lr  abf146e1  pc  abf146f4
    C014C3C  10-09 22:13:19.260  2978  2978 F DEBUG   : backtrace:
    C014C3D  10-09 22:13:19.260  2978  2978 F DEBUG   :       #00 pc 000626f4  /apex/com.android.runtime/lib/bionic/libc.so (abort+172) (BuildId: 5d4259ea3d69ac869057f94ac4f63de5)
    C014C3E  10-09 22:13:19.261  2978  2978 F DEBUG   :       #01 pc 0003956c  /system/lib/libclang_rt.asan-arm-android.so (__sanitizer::Abort()+68) (BuildId: dc587666eacd829dfabfe29f89bfb506d0b28dc7)
    C014C3F  10-09 22:13:19.261  2978  2978 F DEBUG   :       #02 pc 00038394  /system/lib/libclang_rt.asan-arm-android.so (__sanitizer::Die()+192) (BuildId: dc587666eacd829dfabfe29f89bfb506d0b28dc7)
    C014C43  10-09 22:13:19.262  2978  2978 F DEBUG   :       #03 pc 000a4388  /system/lib/libclang_rt.asan-arm-android.so (__asan::ScopedInErrorReport::~ScopedInErrorReport()+428) (BuildId: dc587666eacd829dfabfe29f89bfb506d0b28dc7)
    C014C46  10-09 22:13:19.262  2978  2978 F DEBUG   :       #04 pc 000a65a8  /system/lib/libclang_rt.asan-arm-android.so (__asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool)+2868) (BuildId: dc587666eacd829dfabfe29f89bfb506d0b28dc7)
    C014C4A  10-09 22:13:19.262  2978  2978 F DEBUG   :       #05 pc 000a73ec  /system/lib/libclang_rt.asan-arm-android.so (__asan_report_store4+52) (BuildId: dc587666eacd829dfabfe29f89bfb506d0b28dc7)
    C014C4B  10-09 22:13:19.263  2978  2978 F DEBUG   :       #06 pc 0001b500  /vendor/lib/hw/face.default.so (CameraHelper::onCameraResultAvailable(ACameraMetadata const*)+4432) (BuildId: 8ddba5c8458a31e5fb07bcfed850d17c)
    C014C4C  10-09 22:13:19.263  2978  2978 F DEBUG   :       #07 pc 00011981  /vendor/lib/libcamera2ndk_vendor.so (android::acam::CameraDevice::CallbackHandler::onMessageReceived(android::sp<android::AMessage> const&)+868) (BuildId: 90cd3e2fae377440b102c64d66534146)
    C014C4D  10-09 22:13:19.263  2978  2978 F DEBUG   :       #08 pc 0000f351  /apex/com.android.vndk.v30/lib/libstagefright_foundation.so (android::AHandler::deliverMessage(android::sp<android::AMessage> const&)+24) (BuildId: f002d640b7a30bf48754205868ccc9e7)
    C014C4E  10-09 22:13:19.264  2978  2978 F DEBUG   :       #09 pc 000118f7  /apex/com.android.vndk.v30/lib/libstagefright_foundation.so (android::AMessage::deliver()+82) (BuildId: f002d640b7a30bf48754205868ccc9e7)
    C014C4F  10-09 22:13:19.264  2978  2978 F DEBUG   :       #10 pc 0000fafb  /apex/com.android.vndk.v30/lib/libstagefright_foundation.so (android::ALooper::loop()+526) (BuildId: f002d640b7a30bf48754205868ccc9e7)
    C014C50  10-09 22:13:19.264  2978  2978 F DEBUG   :       #11 pc 0000edd1  /apex/com.android.vndk.v30/lib/libutils.so (android::Thread::_threadLoop(void*)+304) (BuildId: a0048ce05ba06b1b99a1a10279ab97d5)
    C014C51  10-09 22:13:19.265  2978  2978 F DEBUG   :       #12 pc 0000e889  /apex/com.android.vndk.v30/lib/libutils.so (thread_data_t::trampoline(thread_data_t const*)+264) (BuildId: a0048ce05ba06b1b99a1a10279ab97d5)
    C014C52  10-09 22:13:19.265  2978  2978 F DEBUG   :       #13 pc 0008a070  /system/lib/libclang_rt.asan-arm-android.so (asan_thread_start(void*)+80) (BuildId: dc587666eacd829dfabfe29f89bfb506d0b28dc7)
    C014C53  10-09 22:13:19.265  2978  2978 F DEBUG   :       #14 pc 000aaeff  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+40) (BuildId: 5d4259ea3d69ac869057f94ac4f63de5)
    C014C54  10-09 22:13:19.266  2978  2978 F DEBUG   :       #15 pc 00063bfd  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) (BuildId: 5d4259ea3d69ac869057f94ac4f63de5)
    从crash问题log可以看出刚好是meta出现堆溢出,对其进行解析如下:
    
    ==2594==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x89c02f28 at pc 0xa55f0504 bp 0x8a0fbe38 sp 0x8a0fbe34
    WRITE of size 4 at 0x89c02f28 thread T13 (C2N-dev-looper)
        #0 0xa55f0500 in _ZN12CameraHelper23onCameraResultAvailableEPK15ACameraMetadata vendor/xxx/modules/faceunlock/CameraHelper.cpp:444
        #1 0xa9f9497e in _ZNK7android2spI15ACameraMetadataE3getEv system/core/libutils/include/utils/StrongPointer.h:65
        #2 0xa9f9497e in _ZN7android4acam12CameraDevice15CallbackHandler17onMessageReceivedERKNS_2spINS_8AMessageEEE frameworks/av/camera/ndk/ndk_vendor/impl/ACameraDevice.cpp:1072
        #2 0xabda134e  (/apex/com.android.vndk.v30/lib/libstagefright_foundation.so+0xf34e)
        #3 0xabda38f6  (/apex/com.android.vndk.v30/lib/libstagefright_foundation.so+0x118f6)
        #4 0xabda1afa  (/apex/com.android.vndk.v30/lib/libstagefright_foundation.so+0xfafa)
        #5 0xac3abdce  (/apex/com.android.vndk.v30/lib/libutils.so+0xedce)
        #6 0xac3ab886  (/apex/com.android.vndk.v30/lib/libutils.so+0xe886)
        #3 0xac26a070 in asan_thread_start /out/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:205
        #8 0xabf5cefc  (/apex/com.android.runtime/lib/bionic/libc.so+0xaaefc)
        #9 0xabf15bfa  (/apex/com.android.runtime/lib/bionic/libc.so+0x63bfa)
    
    0x89c02f28 is located 0 bytes to the right of 1704-byte region [0x89c02880,0x89c02f28)
    allocated by thread T2 (FaceRequestLoop) here:
        #4 0xac27fe2c in __interceptor_malloc /out/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145
        #5 0xa55eedf4 in _ZN12CameraHelper10initCameraEv vendor/xxx/modules/faceunlock/CameraHelper.cpp:364
        #6 0xa55ee504 in _ZN12CameraHelper25openCameraAndStartPreviewEv vendor/xxx/modules/faceunlock/CameraHelper.cpp:258
        #7 0xa55dfdf0 in _ZL17face_authenticateP11face_devicey vendor/xxx/modules/faceunlock/face.cpp:1806
        #8 0x7e4b840 in _ZN6vendor4sprd8hardware4face4V1_014implementation11FaceHandler17onMessageReceivedERKN7android2spINS6_8AMessageEEE vendor/xxx/interfaces/face/1.0/default/ExtBiometricsFace.cpp:57
        #5 0xa481a47c  ([anon:SizeClassAllocator]+0x1a47c)
    
    Thread T13 (C2N-dev-looper) created by T2 (FaceRequestLoop) here:
        #9 0xac269f24 in StackTrace /out/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_stacktrace.h:53
        #10 0xac269f24 in BufferedStackTrace /out/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_stacktrace.h:98
        #11 0xac269f24 in __interceptor_pthread_create /out/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:214
        #1 0xac3ab720  (/apex/com.android.vndk.v30/lib/libutils.so+0xe720)
    
    Thread T2 (FaceRequestLoop) created by T0 here:
        #12 0xac269f24 in StackTrace /out/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_stacktrace.h:53
        #13 0xac269f24 in BufferedStackTrace /out/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_stacktrace.h:98
        #14 0xac269f24 in __interceptor_pthread_create /out/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:214
        #1 0xac3ab720  (/apex/com.android.vndk.v30/lib/libutils.so+0xe720)

    很明显FaceHAL的CameraHelper.cpp:444出现了堆溢出,查看FaceHAL源码如下:

    camera_data->helpInfo[1+entryHistogram.count+i] = entryHistogram.data.i32[i];
    struct cameradata
    {
        int64_t resultAddr;
         int32_t helpInfo[263];
         uint8_t faceInfo[644];
    };
    查看helpInfo的赋值过程如下:
    camera_data->helpInfo[0] = resultAeState;
    ......
            for (uint32_t i = 0; i < entryAeInfo.count; i ++) {
               camera_data->helpInfo[1+i] = entryAeInfo.data.i32[i];
        }
    .........
            for (uint32_t i = 0; i < entryHistogram.count; i ++) {
               camera_data->helpInfo[1+entryHistogram.count+i] = entryHistogram.data.i32[i];//问题点
        }
    ..........
    camera_data->helpInfo[1+entryAeInfo.count+entryHistogram.count] = deviceOrientation;
    》》对 entryAeInfo &  entryHistogram对应的count打印如下:
    M0093E8  10-11 14:31:43.970   367  1581 I CameraHelper: entryAeInfo count 5
    M009626  10-11 14:31:44.111   367  1581 I CameraHelper: entryHistogram count 256

    显然:1+5+256+1=263,声明无问题

    camera_data->helpInfo[1+entryHistogram.count+i] = entryHistogram.data.i32[i]赋值不应该是这样,这样赋值会存在溢出1+256+256)=513>>263

    改为camera_data->helpInfo[1+entryAeInfo.count+i] = entryHistogram.data.i32[i];才是正确的

    修改后编译FaceHal的库,push face.default.so后已能使K2正常循环buffer

    M00B2D8  10-09 23:23:09.765   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf6fc000
    M00B3B8  10-09 23:23:09.804   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf7fa000
    M00B406  10-09 23:23:09.815   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf8f8000
    M00B502  10-09 23:23:09.868   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf9f6000
    M00B5CA  10-09 23:23:09.951   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbfaf4000
    
    M00C3D0  10-09 23:23:11.099   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf6fc000
    M00C950  10-09 23:23:11.532   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf7fa000
    M00D04A  10-09 23:23:12.282   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf8f8000
    M00D9C7  10-09 23:23:13.283   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf9f6000
    M00E413  10-09 23:23:14.217   337  2037 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbfaf4000
    M0113F9  10-09 23:23:26.771   337  2120 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf6fc000
    M0114BE  10-09 23:23:26.820   337  2120 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf7fa000
    M011615  10-09 23:23:27.020   337  2120 D Cam3SingleFaceIdU: 1100, processCaptureResultMain: check phy addr=0xbf8f8000

    至此,问题已修复,地址踩踏点找到.

    展开全文
  • DS5解决 内存踩踏

    2020-02-11 09:40:13
    0x60b284为踩踏的地址:增加watch point watch point 监测0x60b284 == 3的时候,抓住现场。然后通过mw(改内存指令),把此地址值改成3,可以抓住mw所在线程。图如下: 此时cpu stop,然后在再更改watch ...

    最近发现个问题:malloc出来的几组值(UINT32)总是发生变化,总有地方改他。

    硬件平台:zynq 7045。软件平台 ucos II操作系统。

    这种问题定位起来非常费劲,有可能数组越界,有可能野指针等等。

    不过运气不错,我找到了神器:DS5。

    1.DS5的使用

    硬件连接就不用说了,软件开始。

    1.1 建立工程。

    将代码考入到ds5 目录下 workspace

    File----->Import 

    选择Existing Projects into Workspace,选择next,

    我这已经添加了,所以不能重新添加,添加完成后选择finish即可。

    1.2 debug信息。

    run--->Debug Configurtations

    右键DS-5 Debugger 选择new。

    connection目录下 选择对应的平台。我是zynq 然后选择裸机(下面有linux)。

    file选择编译好的elf格式文件:

    Debugger选择connect only

    os awareness选择对应的裸机操作系统

    然后选择debug即可。

    1.3 开始debug

    分别对应 run,停止 单步调试等信息。

    0x60b284为踩踏的地址:增加watch point

    watch point 监测0x60b284 == 3的时候,抓住现场。然后通过mw(改内存指令),把此地址值改成3,可以抓住mw所在线程。图如下:

    此时cpu stop,然后在再更改watch ponit监测 0x60b284不为3条件时抓现场。

     

    最后发现PC指针指向了 0x10ADB8.把elf格式的文件进行反汇编arm-linux-gcc-objdump - D xxxx.elf > xxxx.txt,

    打开xxx.txt,查找0x10ADB8地址或者附近地址的函数:

    可以看到正好处于这个函数,进行压栈时候出错了:

    为了证实,可以查看ds-5中的cpu的 r0-r4寄存器:

    正好一样,证实了错误的存在。不得不说DS-5真是款神器:

    这样就可以看出了内存分布图出现错误,irq模式下的栈设置到了malloc区域了。

    展开全文
  • 今天遇到一下奇怪的段错误,研究发现原来是内存写越界了。 函数片段如下 ht_insert_he --> ht_index --> hashfunction void ht_insert_he(hash_table *table, hash_entry *entry) { hash_entry *tmp; unsigned ...

    今天遇到一下奇怪的段错误,研究发现原来是内存写越界了。

    函数片段如下 ht_insert_he --> ht_index --> hashfunction

    void
    ht_insert_he(hash_table *table, hash_entry *entry)
    {
        hash_entry *tmp;
        unsigned int index;
    
        entry->timestamp = time(NULL);
        entry->next = NULL;
    
        index = ht_index(table, entry->key, entry->key_size);
        tmp = table->array[index]; //段错误出现位置
    
        ......
    
    }

    unsigned int 
    ht_index(hash_table *table, void *key, size_t key_size)
    {
        uint32_t index; //32位变量
        table->hashfunction(key, key_size, global_seed, &index);
        index %= table->array_size;
        return index;
    }

    其中hashfunction实现如下
    void 
    hashfunction(const void *key, const int len, const uint32_t seed, void *out)
    {
        const uint8_t * data = (const uint8_t*)key; 
        const int nblocks = len / 16;
    
    	......
    
        ((uint64_t*)out)[0] = h1; //把最后一个参数当64位进行写操作
        ((uint64_t*)out)[1] = h2;
    }


    !!!把32位变量index的地址传给了hashfunction,而hashfunction把它当成了64位变量进行写入,破坏了函数栈

    展开全文
  • /* Hello World Example This example code is in the Public Domain (or CC0 licensed, at your option.) Unless required by applicable law or agreed to in writing, this software is distributed on an ...
  • 对于C/C++代码来说,逻辑错误固然可能产生bug(事实上这种bug是不管哪种语言都难以避免的),不过更可怕的是内存相关的bug,对内存的任何错误操作都会导致严重的后果,而且内存踩踏导致的程序异常如果不能在线debug...
  • 首先说明下,作者本人是C/C++程序员...同时,内存错误往往非常严重,一般会带来诸如系统崩溃,内存耗尽(OOM),逻辑异常(内存踩踏)这样严重的后果。这些后果,都是无法接受的。最要命的是内存泄漏通常是无声无息...
  • 每当遇到内存踩踏的问题,总要深深的口气,哎又要被蹂躏几个月了。这么多年来自己倒是也思考和总结了诊断内存问题的方法、技巧,也开发了一些诊断工具。但是这些工具还是不能预防,也不能解决普遍的问题,只能在遇到...
  • 检查堆内存的问题,定位到文件,行数 1. 踩内存 2. 内存重复释放 3. 内存泄露 使用方法用 dbg_malloc, dbg_free 替换原程序中的malloc, free. 适当的时候调用dbg_memory_check 以检查内存泄露。 原理: ...
  • Node.js的缓存模块,它使用两级缓存(内存缓存用于最近访问的数据,Redis用于分布式缓存),并具有自动序列化功能,以及一些额外的功能,可避免缓存踩踏和雷声大浪。 还包括互斥量和信号量分布式锁定原语。 特征 ...
  • 内存溢出和内存泄漏

    千次阅读 2018-05-02 22:29:25
    通俗理解就是内存不够,通常在运行大型软件或游戏时,软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小,就叫内存溢出。此时软件或游戏就运行不了,系统会提示内存溢出,有时候会自动关闭软件,重启...
  • 主要介绍:new/delete的使用方法概述,常见的问题:new/delete表达式与malloc/free的区别,malloc的底层实现?free如何回收内存?什么是内存泄漏,内存溢出,内存踩踏,野指针?
  • 故障调试能力:发生内存泄漏和踩踏时,可追溯位置,便于定位故障 管理成本小:管理的代码本身占用空间小,从空间复杂度 申请和释放效率高:时间复杂度 FreeRTOS的heap_5算法 相比 heap_4 支持地址不...
  • 内存泄漏 内存泄漏(memory leak)是指由于疏忽或错误造成了程序未能释放掉不再使用的内存的情况。内存泄漏并非指内存在物理意义上的消失,而是应用程序分配某段内存后,由于设计错误,失去了对该段内存的控制,...
  • 问题定位:内存泄漏,踩内存

    万次阅读 2013-07-27 00:27:40
    1.内存泄漏  确定现象:  linux 内存泄漏,可以查看slabinfo 和另外一个proc下(貌似meminfo),关于内存的信息,可以看到内存是否在不断减少,以及减少的速度。  vxworks系统,内存是否有相关信息???  如果...
  • 内存问题一直是C/C++程序员的心头大患,因为没有GC机制,所以需要我们自己管理内存。在 从“new和malloc的不同”出发看CC++的内存分配 一文中,讲述了几种内存错误的例子,那么避免这些陷阱呢? 1. new/delete 、...
  • 内存泄漏是指是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。 我们在删除一个指针之后,编译器只会释放该指针所指向的内存空间...
  • 内存越界/内存泄露

    2020-03-16 16:21:29
    查看内存: cat /proc/media-mem |-MMB: phys(0x835D3000, 0x835E6FFF), kvirt=0x (null), flags=0x00000000, length=80KB, name=“xxx” |-MMB: phys(0x835E7000, 0x836C7FFF), kvirt=0x (null), flags=0x00000000...
  • 内存调优工具 内存调优的时候要更多地使用JDK提供的内存查看工具,比如JConsole和Java VisualVM。 内存调优思路 对JVM内存的系统级调优主要的方法是减少GC的频率和Full GC的次数,过多的GC和Full GC是会占用很多的...
  • 首先说一下内存异常的一些常用概念: 内存泄露:malloc申请堆内存时...内存踩踏:访问越界导致腹泻了非目标地址内的数据,常见于循环访问数组时设置循环次数有误,导致访问越界,写入数据将非数组内的变量也覆盖掉了;
  • Arm-kernel 内存收集

    千次阅读 2011-07-23 11:24:26
    本文介绍和分析arm-kernel如何收到物理内存信息。
  • 一文读懂踩内存

    2021-01-26 16:13:38
    2. 踩内存的可能的情形 1)内存访问越界 a)数组访问越界; b)字符串操作越界; 2)非法指针 a)使用了空指针; b)使用了释放掉的指针; c)指针类型转换错误; 3)栈溢出; 4)多线程读写的数据没有...
  • 内存内存重叠)的处理

    千次阅读 2018-06-06 01:11:19
    memcpy和memmove()都是C语言中的库函数,在头文件string.h中,作用是拷贝一定长度的内存的内容,原型分别如下:[cpp] view plaincopyprint?void *memcpy(void *dst, const void *src, size_t count); void...
  • linux内存调试

    2020-01-11 13:55:58
    linux内存不够用了 查看内存消耗排名 ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|head
  • 关于踩内存

    千次阅读 2020-03-07 15:55:53
    1.什么是踩内存 访问了不合法的地址 。通俗一点就是访问了不属于自己的地址。如果这块地址分配给了另一个变量使用,就会破坏别人的数据。从而导致程序运行异常,挂死,输出图像破图等。 2.踩内存的可能的情形 1...
  • 栈溢出问题分析

    千次阅读 2018-02-03 14:46:18
    在这种情况下,只有几种情况可能出现:内存踩踏、栈溢出。 在经过长时间的分析确认,肯定不是内存踩踏。剩下的就是栈溢出了。Linux下一般单个程序栈大小为10M,可用ulimit -s查阅。一般情况下,10M的大小足够用,怎...
  • 内存泄漏是指我们在堆中申请(new/malloc)了一块内存,但是没有去手动的释放(delete/free)内存,导致指针已经消失,而指针指向的东西还在,已经不能控制这块内存, 所以就是内存泄漏了,看下面的例子。 void ...
  • 6如何停止正在发生的缓存踩踏 Facebook 的缓存踩踏事件之所以如此具有破坏性,其原因之一是即使工程师找到了解决方案,也无法进行部署,因为踩踏事件仍在进行当中。 事后诊断报告提到: 更糟糕的是,每次客户端在...
  • 指向一个已删除的对象或未申请访问受限内存区域的指针。与空指针不同,野指针无法通过简单地判断是否为 NULL避免,而只能通过养成良好的编程习惯来尽力减少。对野指针进行操作很容易造成程序错误。 1.指针...
  • 内存问题,个人认为算是比较容易出现但是有很难定位的问题,被踩者轻者功能瘫痪,重者一命呜呼,直接诱发死机。产生踩内存的的原因也比较多样,比较典型的有如下几种: 数组越界访问 字符串越界操作 直接操作...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 397
精华内容 158
关键字:

内存踩踏