• 基本c功能使用不当导致崩溃


    一些基本的c语言操作,使用不当也会有出其不意的问题。
    比如我最近的一个项目中,用到几句代码:

    uint8_t * out_pcm = NULL;
    .......
    
    if (NULL == out_pcm)
        out_pcm = (uint8_t *)malloc(AEC_CACHE_LEN*sizeof(uint8_t));
    .......
    
    if(out_pcm) 
        free(out_pcm);

    表面看没得问题。
    实际项目中情况要复杂一些。我在安卓服务里,启动一个窗口里使用这几句代码,然后关闭窗口。反复打开关闭几次就崩溃。
    使用Android Studio分析崩溃原因,每次都是看到这样的日志:

    12-14 16:30:01.100 F/libc    (21786): invalid address or address of corrupt block 0x7d85f108 passed to dlfree
    12-14 16:30:01.100 F/libc    (21786): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 21786 (com.spt.rvis)
    12-14 16:30:01.150 I/DEBUG   (  159): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    12-14 16:30:01.150 I/DEBUG   (  159): Build fingerprint: 'hcd/rk3288/rk3288:4.4.4/KTU84Q/eng.zhantaiming.20170701.151949:eng/test-keys'
    12-14 16:30:01.150 I/DEBUG   (  159): Revision: '0'
    12-14 16:30:01.150 I/DEBUG   (  159): pid: 21786, tid: 21786, name: com.spt.rvis  >>> com.spt.rvis <<<
    12-14 16:30:01.150 I/DEBUG   (  159): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
    12-14 16:30:01.150 I/DEBUG   (  159): Abort message: 'invalid address or address of corrupt block 0x7d85f108 passed to dlfree'
    12-14 16:30:01.250 I/DEBUG   (  159):     r0 00000000  r1 40157066  r2 deadbaad  r3 4015aba8
    12-14 16:30:01.250 I/DEBUG   (  159):     r4 7d85f108  r5 40165180  r6 41a32000  r7 7d85f110
    12-14 16:30:01.250 I/DEBUG   (  159):     r8 7993dfe0  r9 79a54c60  sl 79afe260  fp 00000000
    12-14 16:30:01.250 I/DEBUG   (  159):     ip 00000001  sp bebb01d0  lr 40128757  pc 40128758  cpsr 600f0030
    12-14 16:30:01.250 I/DEBUG   (  159):     d0  2064657373617064  d1  6120726f2073736c
    12-14 16:30:01.250 I/DEBUG   (  159):     d2  6f20737365726466  d3  707572726f632072
    12-14 16:30:01.250 I/DEBUG   (  159):     d4  000000007d3d2548  d5  0000000000000040
    12-14 16:30:01.250 I/DEBUG   (  159):     d6  0000000000000008  d7  000000007d3d254c
    12-14 16:30:01.250 I/DEBUG   (  159):     d8  0000000000000000  d9  0000000000000000
    12-14 16:30:01.250 I/DEBUG   (  159):     d10 0000000000000000  d11 0000000000000000
    12-14 16:30:01.250 I/DEBUG   (  159):     d12 0000000000000000  d13 0000000000000000
    12-14 16:30:01.250 I/DEBUG   (  159):     d14 0000000000000000  d15 0000000000000000
    12-14 16:30:01.250 I/DEBUG   (  159):     d16 0000000000000004  d17 0000000000000000
    12-14 16:30:01.250 I/DEBUG   (  159):     d18 000000007d3d2588  d19 0000000000000001
    12-14 16:30:01.250 I/DEBUG   (  159):     d20 8000800080008000  d21 8000800080008000
    12-14 16:30:01.250 I/DEBUG   (  159):     d22 0000000000004000  d23 0000000000000001
    12-14 16:30:01.250 I/DEBUG   (  159):     d24 0000000000000008  d25 0000000000000040
    12-14 16:30:01.250 I/DEBUG   (  159):     d26 0000000000000038  d27 fffc8000fffd8000
    12-14 16:30:01.250 I/DEBUG   (  159):     d28 0004000500060007  d29 0000000100020003
    12-14 16:30:01.250 I/DEBUG   (  159):     d30 0000000000000000  d31 0000000000000000
    12-14 16:30:01.250 I/DEBUG   (  159):     scr 28000012
    12-14 16:30:01.260 I/DEBUG   (  159):
    12-14 16:30:01.260 I/DEBUG   (  159): backtrace:
    12-14 16:30:01.260 I/DEBUG   (  159):     #00  pc 00011758  /system/lib/libc.so (dlfree+1191)
    12-14 16:30:01.260 I/DEBUG   (  159):     #01  pc 0000dca7  /system/lib/libc.so (free+10)
    .....................................
    12-14 16:30:01.260 I/DEBUG   (  159):     #21  pc 0000105b  /system/bin/app_process
    12-14 16:30:01.260 I/DEBUG   (  159):     #22  pc 0000e3e7  /system/lib/libc.so (__libc_init+50)
    12-14 16:30:01.260 I/DEBUG   (  159):     #23  pc 00000d7c  /system/bin/app_process
    12-14 16:30:01.260 I/DEBUG   (  159):
    12-14 16:30:01.260 I/DEBUG   (  159): stack:
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0190  40161000  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0194  79a81fb0  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0198  7cdfb5c8  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb019c  5fec8d00  /dev/ashmem/dalvik-heap (deleted)
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01a0  7d85f108  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01a4  40165180
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01a8  41a32000  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01ac  40129ac5  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01b0  40157066  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01b4  bebb01c4  [stack]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01b8  4015aba8  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01bc  40128757  /system/lib/libc.so (dlfree+1190)
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01c0  40157066  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01c4  7d85f108  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01c8  4015aba8  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01cc  00000000
    12-14 16:30:01.260 I/DEBUG   (  159):     #00  bebb01d0  40161000  /system/lib/libc.so
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01d4  7bae5518  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01d8  7bae4020  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01dc  00000000
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01e0  7bae5948  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01e4  40124ca9  /system/lib/libc.so (free+12)
    12-14 16:30:01.260 I/DEBUG   (  159):     #01  bebb01e8  bebb01ec  [stack]
    12-14 16:30:01.260 I/DEBUG   (  159):     #02  bebb01f0  79ad6558  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01f4  00001588
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01f8  5fec8d00  /dev/ashmem/dalvik-heap (deleted)
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb01fc  00000001
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0200  7bae4020  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0204  79afe1a0  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0208  40165384
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb020c  7bbe5a78  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0210  7bae5948  [anon:libc_malloc]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0214  41c54480  [heap]
    12-14 16:30:01.260 I/DEBUG   (  159):          bebb0218  bebb029c  [stack]

    日志中可以看出,出错的地方都是内存的基本操作,位于libc.so中。一般都是malloc,free,memcpy,memset这类的操作。
    加了一些才发现,多次循环后,再次进入
    if (NULL == out_pcm)
    out_pcm = (uint8_t *)malloc(AEC_CACHE_LEN*sizeof(uint8_t));
    因为out_pcm定义为全局变量,并不为NULL,并不会重新malloc,但是退出的时候仍然去free。

    解决方法:

    if(out_pcm) 
    {
        free(out_pcm);
        out_pcm = NULL;
    }

    少定义全局的变量。

  • 相关阅读:
    zend framework多模块配置
    java解析xml的几种方式
    jdbc操作步骤和preparedStatment相比Statment的好处
    Android UI 之实现多级列表TreeView
    python小游戏实现代码
    【iOS知识学习】_UITableView简介
    根据指定电话号码得到通讯录上的姓名
    HDU 4705 Y
    C#实现的内存分页机制的一个实例
    【编程程序猿艺术】学习记录1:指针向左翻转法的旋转串
  • 原文地址:https://www.cnblogs.com/zzugyl/p/8040016.html
Copyright © 2020-2023  润新知