是否可以在不使用pmap或wdb的情况下确定HPUX PA-RISC seg故障的原因

Is it possible to determine the cause of a HPUX PA-RISC seg fault without using pmap or wdb?

本文关键字：情况下 HPUX seg 故障 PA-RISC wdb pmap 是否      更新时间：2023-10-16

我们在使用HPUX PARISC编译器和链接器ACC编译的C/C++HPUX PA-RISC应用程序RELEASE演示中遇到随机发生的分段错误，该演示加载了与ACC编译和链接的HPUX PA_RISC RELEASE共享对象sl（即so）。我们无法访问pmap或HPUX wdb。因此，我们正在使用HP的专有调试器adb。以下是我们如何使用adb:

$ adb
PA-32 adb ($h help $q quiit)
adb>!cp mdMUReadWriteExample a.out
!
adb>:r
a.out: running (process 10947)
segmentation violation
stopped at      1E3C:           STW             r3,1416(r1)

在这一点上，违规指令似乎在某种程度上与上述程序集的构建有关。我们的第一个问题是1416是十进制格式还是十六进制格式。

我们的第二个问题是程序计数器1E3C是否准确，是否可以用于获得有关有问题的C/C++源代码行/的进一步信息

我们的第三个问题是，假设1416是十进制格式，那么如下所示，寄存器1($r1)包含0x40015b90。使用十六进制算术1416（基数为10（即十六进制0x588））+0x40015b90等于0x40016118。接下来，我们使用nm来查找与0x40016118相关联的共享对象库地址/C++损坏符号。

$ grep -n "4001611" /home/marc/acc3_pa_32bit/cameron_nm.txt
27808:40016118 ? static___soa_RSA_cpp_
27823:40016110 ? static___soa_cDateTime_cpp_

接下来，我们修改makefile以获得组合反汇编——C++源代码。然而，当我们搜索所有生成的50个*.s文件时，我们无法神秘地找到static___soa_RSA_cpp_。我们是否跳过了关键的一步？

adb>$r
pcoqh 0   1E3F
pcoqt 0   1E43
rp    0   0xC0209793
arg0 0  1         arg1 0   7F7F04FC  arg2 0   7F7F050 4   arg3 0   7F7F0540
sp   0  7F7F05D0  ret0 0   0         ret1 0   1           dp   0   40016390
r1   0  40015B90  r3   0   7F7F0000  r4   0   4001591 8   r5   0   3C
r6   0  20        r7   0   3E        r8   0   7F7F091 0   r9   0   40015918
r10  0  40031918  r11  0   1E800     r12  0   4001611 8   r13  0   400266A4
r14  0  3F        r15  0   3F        r16  0   3D          r17  0   3D
r18  0  3A        r19  0   7B03B764  r20  0   0xA98D4 00  r21  0   7F7F0550
r22  0  0         r31  0   1E2B      sar  0   23          sr0  0   0xA98D400
sr1  0  3848400   sr2  0   0         sr3  0   0           sr4  0   0xA98D400

总之，我们正在尝试确定是否有可能找到导致此随机seg故障的有问题的C/C++源线。使用Centos Linux和valgrind --tool=memcheck，我们找不到任何缓冲区溢出。非常感谢。

晚上好，我学会了如何使用HPUX PA-RISC获得分段故障堆栈跟踪。需要4个步骤1）#include"unvel.h"#include"signal.h"2）定义一个外部"C"U_STACK_TRACK（int）函数原型3）在主函数中声明一个SIGSEGV处理程序：signal（SIGSEGV，U_STACK_TRACE）。4） 在makefile中，链接到libcl.Regards，Frank Tzepu Chang

$mdMUReadWriteExample（0）0xc01fef60 _sigreturn[/usr/lib/libc.2]（1）0xc2f27b90 _ct_7CBigNumFv_2+0x88[./libmdMatchup.sl]（2）0xc2f3c83c RSADecrypt_FPCcN21Pc+0x24[./libmdMatchup.sl]（3）0xc2f314ec解密许可证_9mdLicenseFPCcPc+0x44[./libmdMatchup.sl]（4）0xc2f31280 DecryptDecodeTest_9mdLicenseFPCcT1+0x40[./libmdMatchup.sl]（5）0xc2f30c3c测试许可证_9mdLicenseFPCc+0xb4[./libmdMatchup.sl]（6）0xc2d783bc SetLicenseString_12cBatchDedupeFPCc+0x5c[./libmdMatchup。sl]（7）0xc2d6c908 SetLicenseString_13mdMU读写FPCc+0x90[./libmdMatchup.sl]（8）0x0000376c主+0x68[./mdMUReadWriteExample]（9）0xc01409f8 _start+0xa0[/usr/lib/libc.2]（10） 0x00002008$START$+0x178[./mdMUReadWriteExample]分段故障（堆芯转储）

相关文章：