执行C ++代码的Android崩溃无法通过ADB Shell复制

Question

我在应用程序中遇到了严重的崩溃问题，并且我也失去了剩下的小头发。

问题是：如果我执行我的程序（用C ++编写11）亚行外壳， 没有崩溃。 但是我仍然在日食模拟器和设备上都得到了SIGSEGV。

我必须通过一个简单的应用程序执行该程序：

Android应用程式码：

public BufferedReader startExample() {
    String[] commandLine2 = {"/system/app/example", "/system/app/conf.xml"};

    System.out.println("Example launched with "+currentScript);

    Process process = null;

    try {
        process = Runtime.getRuntime().exec(commandLine2);
        reader = new BufferedReader(new InputStreamReader(process.getInputStream()));   
        writer = new OutputStreamWriter(process.getOutputStream());
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
    return reader;
}

我在Logcat上收到的输出是这样的：

05-26 16:13:45.680: I/DEBUG(65): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-26 16:13:45.680: I/DEBUG(65): Build fingerprint: 'google/passion/passion:2.3.6/GRK39F/189904:user/release-keys'
05-26 16:13:45.680: I/DEBUG(65): pid: 2573, tid: 2573  >>> /system/app/example <<<
05-26 16:13:45.680: I/DEBUG(65): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
05-26 16:13:45.680: I/DEBUG(65):  r0 00000027  r1 deadbaad  r2 a0000000  r3 00000000
05-26 16:13:45.680: I/DEBUG(65):  r4 00000001  r5 00000000  r6 001405d4  r7 00144838
05-26 16:13:45.680: I/DEBUG(65):  r8 000eb53c  r9 00000000  10 00000000  fp beba99b4
05-26 16:13:45.680: I/DEBUG(65):  ip afd46668  sp beba97f8  lr afd191d9  pc afd15ca4  cpsr 60000030
05-26 16:13:45.680: I/DEBUG(65):  d0  6772615f64696c75  d1  206e69687469776d
05-26 16:13:45.680: I/DEBUG(65):  d2  7574706163206f65  d3  6874206e6f20656e
05-26 16:13:45.680: I/DEBUG(65):  d4  2030202020203020  d5  2020203020202020
05-26 16:13:45.680: I/DEBUG(65):  d6  3020202020202020  d7  2020202020202020
05-26 16:13:45.680: I/DEBUG(65):  d8  0000000000000000  d9  0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  d10 0000000000000000  d11 0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  d12 0000000000000000  d13 0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  d14 0000000000000000  d15 0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  d16 bfa11178a5a14a1b  d17 bfa0c9714fbcda40
05-26 16:13:45.680: I/DEBUG(65):  d18 bfa0e1b8218a374c  d19 bf91111111111116
05-26 16:13:45.680: I/DEBUG(65):  d20 0000000000000000  d21 3fd99999ac013de9
05-26 16:13:45.680: I/DEBUG(65):  d22 3fd24924a3334279  d23 3fcc71c536ee839c
05-26 16:13:45.680: I/DEBUG(65):  d24 3fc74664af50539d  d25 3fc39a09d078c69f
05-26 16:13:45.680: I/DEBUG(65):  d26 0000000000000000  d27 0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  d28 0000000000000000  d29 0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  d30 0000000000000000  d31 0000000000000000
05-26 16:13:45.680: I/DEBUG(65):  scr 00000010
05-26 16:13:45.680: I/DEBUG(65):          #00  pc 00015ca4  /system/lib/libc.so
05-26 16:13:45.680: I/DEBUG(65):          #01  lr afd191d9  /system/lib/libc.so
05-26 16:13:45.680: I/DEBUG(65): code around pc:
05-26 16:13:45.680: I/DEBUG(65): afd15c84 2c006824 e028d1fb b13368db c064f8df 
05-26 16:13:45.680: I/DEBUG(65): afd15c94 44fc2401 4000f8cc 49124798 25002027 
05-26 16:13:45.680: I/DEBUG(65): afd15ca4 f7f57008 2106ec7c edd8f7f6 460aa901 
05-26 16:13:45.680: I/DEBUG(65): afd15cb4 f04f2006 95015380 95029303 e93ef7f6 
05-26 16:13:45.680: I/DEBUG(65): afd15cc4 462aa905 f7f62002 f7f5e94a 2106ec68 
05-26 16:13:45.680: I/DEBUG(65): code around lr:
05-26 16:13:45.680: I/DEBUG(65): afd191b8 4a0e4b0d e92d447b 589c41f0 26004680 
05-26 16:13:45.680: I/DEBUG(65): afd191c8 686768a5 f9b5e006 b113300c 47c04628 
05-26 16:13:45.680: I/DEBUG(65): afd191d8 35544306 37fff117 6824d5f5 d1ef2c00 
05-26 16:13:45.680: I/DEBUG(65): afd191e8 e8bd4630 bf0081f0 00028344 ffffff88 
05-26 16:13:45.680: I/DEBUG(65): afd191f8 b086b570 f602fb01 9004460c a804a901 
05-26 16:13:45.680: I/DEBUG(65): stack:
05-26 16:13:45.680: I/DEBUG(65):     beba97b8  afd42664  
05-26 16:13:45.680: I/DEBUG(65):     beba97bc  00147930  
05-26 16:13:45.680: I/DEBUG(65):     beba97c0  0000001a  
05-26 16:13:45.680: I/DEBUG(65):     beba97c4  afd182a1  /system/lib/libc.so
05-26 16:13:45.680: I/DEBUG(65):     beba97c8  afd4270c  
05-26 16:13:45.680: I/DEBUG(65):     beba97cc  afd426b8  
05-26 16:13:45.680: I/DEBUG(65):     beba97d0  00000000  
05-26 16:13:45.680: I/DEBUG(65):     beba97d4  afd191d9  /system/lib/libc.so
05-26 16:13:45.680: I/DEBUG(65):     beba97d8  00000001  
05-26 16:13:45.680: I/DEBUG(65):     beba97dc  beba980c  
05-26 16:13:45.680: I/DEBUG(65):     beba97e0  001405d4  
05-26 16:13:45.680: I/DEBUG(65):     beba97e4  00144838  
05-26 16:13:45.680: I/DEBUG(65):     beba97e8  000eb53c  /system/app/example
05-26 16:13:45.680: I/DEBUG(65):     beba97ec  afd184fb  /system/lib/libc.so
05-26 16:13:45.690: I/DEBUG(65):     beba97f0  df002777  
05-26 16:13:45.690: I/DEBUG(65):     beba97f4  e3a070ad  
05-26 16:13:45.690: I/DEBUG(65): #00 beba97f8  0000000a  
05-26 16:13:45.690: I/DEBUG(65):     beba97fc  afd1c80f  /system/lib/libc.so
05-26 16:13:45.690: I/DEBUG(65):     beba9800  0000000a  
05-26 16:13:45.690: I/DEBUG(65):     beba9804  afd426b8  
05-26 16:13:45.690: I/DEBUG(65):     beba9808  001405d4  
05-26 16:13:45.690: I/DEBUG(65):     beba980c  fffffbdf  
05-26 16:13:45.690: I/DEBUG(65):     beba9810  05000000  
05-26 16:13:45.690: I/DEBUG(65):     beba9814  afd42610  
05-26 16:13:45.690: I/DEBUG(65):     beba9818  00000001  
05-26 16:13:45.690: I/DEBUG(65):     beba981c  000eb654  /system/app/example
05-26 16:13:45.690: I/DEBUG(65):     beba9820  0013fe40  
05-26 16:13:45.690: I/DEBUG(65):     beba9824  00000000  
05-26 16:13:45.690: I/DEBUG(65):     beba9828  0000004e  
05-26 16:13:45.690: I/DEBUG(65):     beba982c  0013fe40  
05-26 16:13:45.690: I/DEBUG(65):     beba9830  00000055  
05-26 16:13:45.690: I/DEBUG(65):     beba9834  0000004e  
05-26 16:13:45.690: I/DEBUG(65):     beba9838  00000047  
05-26 16:13:45.690: I/DEBUG(65):     beba983c  000ad0a0  /system/app/example
05-26 16:13:45.710: I/BootReceiver(96): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)

我已经搜索了stackoverflow和Internet，但是没有一个适合我的问题的问答。 我认为这可能是由C ++代码中的内存管理API中的某种错误引起的，但是我感到困惑，因为使用adb shell启动程序不会产生任何错误。

您是否知道我应该继续解决此问题？ 提前致谢

编辑旧的亲爱的手动调试始终是最好的（即使有点太慢）。 对于那些会遇到类似麻烦的人：

m_source = pcap_open_live(name.c_str(),BUFSIZ,1 ,10,errbuf);
if(!m_source) {
    throw(std::invalid_argument("TcpPcapSource::error within pcap_open_live"));
}

崩溃发生在throw命令。 pcap希望程序以超级用户的权限运行，而我当时使用了错误的命令。 一旦我使该应用程序使用su / sudo（取决于您的adb版本）执行程序，该错误就消失了。

Answer 1

如何逐步从C ++代码中删除内容，直到错误消失。 这样，您将能够找到导致问题的代码区域。 我知道这是一个痛苦而缓慢的方法，但这可能是我在您遇到的情况下不得不采取的措施。

Answer 2

这是错误，是细分错误： http : //en.wikipedia.org/wiki/SIGSEGV

分段错误（通常简称为段错误），总线错误或访问冲突通常是尝试访问CPU无法物理寻址的内存。 （即等效于空指针异常）

以下是分段错误的一些典型原因：

• 试图执行无法正确编译的程序。 尽管存在编译时错误，某些编译器仍将输出可执行文件。
• 解引用NULL指针
• 试图访问内存的程序无权（例如，进程上下文中的内核结构）
• 尝试访问不存在的内存地址（进程的外部地址空间）
• 尝试写入只读存储器（例如代码段）
• 缓冲区溢出
• 使用未初始化的指针

因此，您应该在代码中搜索可能发生上述某些错误的位置！