oops的解读方法-----怎么通过oops查找源码行

Ap6255 调试记录 最近添加了一款ap6266的wifi芯片 wifi一直打不开 采用手动打开也无效 CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP=n echo 1 > /sys/class/rkwifi/power echo 1 > /sys/class/rkwifi/drivernetcfg wlan0 up iwlist wlan scanroot@rk3288:/ 阅读详情

-----------------------------------------------------------------------
本文系本站原创,欢迎转载!
转载请注明出处:http://blog.youkuaiyun.com/android_huber
交流邮箱:dp.shao@gmail.com
-----------------------------------------------------------------------

    今天很郁闷的遇到了一个oops,以前碰到这类事情我就会退缩的,今天刚好没有任务,就想要不就分析一下,这个还是很重要的,我不能总是逃避这类问题啊,果断开始分析了。

    先把oops亮出来给大伙看看,

[ 230.893864] Unable to handle kernel paging request at virtual address 
9c0d5030
[ 230.959592] pgd = 9aaf8000
[ 230.962313] [9c0d5030] *pgd=aa003011, *pte=00000000, *ppte=00000000
[ 231.001197] Internal error: Oops: 7 [#1] PREEMPT
[ 231.005821] last sysfs file: 
/sys/devices/platform/wakeup_event-driver/wakeup_source
[ 231.013571] Modules linked in: dhd(-)
[ 231.017270] CPU: 0 Not tainted (2.6.35.3 #1)
[ 231.022037] PC is at dhdsdio_htclk+0x28/0x438 [dhd]
[ 231.026977] LR is at dhdsdio_clkctl+0x5c/0x108 [dhd]
[ 231.031950] pc : [<7f012d84>] lr : [<7f013490>] psr: 20000013
[ 231.031956] sp : 9ae41e30 ip : 00000000 fp : 2b3408f0
[ 231.043450] r10: 35c61ef0 r9 : 9ae40000 r8 : 00000001
[ 231.048681] r7 : 00000000 r6 : 00000000 r5 : 9c096000 r4 : 9c09f000
[ 231.055217] r3 : 00000000 r2 : 9c0d5000 r1 : 00004329 r0 : 9c09f000
[ 231.061754] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 231.068898] Control: 10c5387d Table: aaaf8019 DAC: 00000015
[ 231.074652] Process WifiService (pid: 2580, stack limit = 0x9ae402e8)
[ 231.081100] Stack: (0x9ae41e30 to 0x9ae42000)
[ 231.085468] 1e20: 9ae41eb4 803f17d0 20000093 80814e28
[ 231.093659] 1e40: 94073900 80814e28 00000001 20000013 9c1dc714 
9c09f000 00000003 00000000
[ 231.101850] 1e60: 9c1dc03c 00000001 9ae40000 35c61ef0 2b3408f0 
7f013490 9c09f000 00000000
[ 231.110042] 1e80: 9ae636c0 7f0155b0 9c09f000 00000001 9ae41e68 
00000000 9c1dc000 9c1dc0a8
[ 231.118234] 1ea0: 9c1df000 9c1dc03c 8004c0c4 7f00142c 9c1dc000 
7f00159c 9c09f000 9ae636c0
[ 231.126426] 1ec0: 7f025240 67e04660 8004c0c4 7f014638 7f025228 
9c093000 7f025240 7f01b24c
[ 231.134617] 1ee0: 922df400 7f02337c 922df43c 802ebcd0 922df408 
7f02337c 922df43c 802178b0
[ 231.142809] 1f00: 922df408 7f02337c 922df43c 80217980 7f02337c 
00000000 80846374 80216c24
[ 231.151000] 1f20: 7f0233b0 00000000 9ae41f44 7f01b3d0 7f0233b0 
7f01b5b0 7f0233b0 8009b1d4
[ 231.159191] 1f40: 00000000 00646864 00000000 9ad9f8dc 00000001 
39c2a6d3 00015e23 00000000
[ 231.167382] 1f60: ffffffff 00000000 00000000 39dd6b48 00000003 
00000003 39dd6c10 00000107
[ 231.175573] 1f80: 7f0233b0 00000880 9ae41f8c 00000000 39dd6b48 
ffffffff 67e04544 00000009
[ 231.183764] 1fa0: 00000081 8004bf40 ffffffff 67e04544 67e04660 
00000880 35c61f34 33d63f1c
[ 231.191955] 1fc0: ffffffff 67e04544 00000009 00000081 39dd6b68 
35c61f04 35c61ef0 2b3408f0
[ 231.200147] 1fe0: 67e06288 39dd6b30 67e03f01 6fd0c44c 20000010 
67e04660 7fff6d67 fdf7f39f
[ 231.208458] [<7f012d84>] (dhdsdio_htclk+0x28/0x438 [dhd]) from 
[<7f013490>] (dhdsdio_clkctl+0x5c/0x108 [dhd])
[ 231.218497] [<7f013490>] (dhdsdio_clkctl+0x5c/0x108 [dhd]) from 
[<7f0155b0>] (dhd_bus_stop+0x48/0x2ac [dhd])
[ 231.228426] [<7f0155b0>] (dhd_bus_stop+0x48/0x2ac [dhd]) from 
[<7f00142c>] (dhd_bus_detach+0x2c/0x44 [dhd])
[ 231.238242] [<7f00142c>] (dhd_bus_detach+0x2c/0x44 [dhd]) from 
[<7f00159c>] (dhd_detach+0x158/0x1c0 [dhd])
[ 231.247993] [<7f00159c>] (dhd_detach+0x158/0x1c0 [dhd]) from 
[<7f014638>] (dhdsdio_release+0x40/0xcc [dhd])
[ 231.257861] [<7f014638>] (dhdsdio_release+0x40/0xcc [dhd]) from 
[<7f01b24c>] (bcmsdh_remove+0x1c/0x8c [dhd])
[ 231.267779] [<7f01b24c>] (bcmsdh_remove+0x1c/0x8c [dhd]) from 
[<802ebcd0>] (sdio_bus_remove+0x18/0x54)
[ 231.277116] [<802ebcd0>] (sdio_bus_remove+0x18/0x54) from [<802178b0>] 
(__device_release_driver+0x84/0xd0)
[ 231.286790] [<802178b0>] (__device_release_driver+0x84/0xd0) from 
[<80217980>] (driver_detach+0x84/0xac)
[ 231.296287] [<80217980>] (driver_detach+0x84/0xac) from [<80216c24>] 
(bus_remove_driver+0x90/0xb8)
[ 231.305324] [<80216c24>] (bus_remove_driver+0x90/0xb8) from 
[<7f01b3d0>] (sdio_function_cleanup+0xc/0x2c [dhd])
[ 231.315522] [<7f01b3d0>] (sdio_function_cleanup+0xc/0x2c [dhd]) from 
[<7f01b5b0>] (dhd_module_cleanup+0x8/0x14 [dhd])
[ 231.326140] unwind: Index not found 7f01b5b0
[ 231.330421] Code: 0a0000d5 e5902008 e3041329 e5d031d8 (e5920030)
[ 232.176926] ---[ end trace 23c706acef457857 ]---

    从上面很明显的可以看出是一个dhd模块出错了,在我的这个板子上是一个wifi的驱动,

    这么一大串,吓到了。。。。

    乍看是在dhdsdio_htclk这个函数中出错了,因为有这么一个片段的log啊

PC is at dhdsdio_htclk+0x28/0x438 [dhd]

此是pc的值是在dhdsdio_htclk这个函数的范围内(啥,,你不知道pc是啥玩意,,那这个就靠你自己去google一下啦)

下面我要做的事情就是要将这个函数所对应的c文件产生的.o文件反汇编一下,如下:

./prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-objdump -D external/linux-bcm4329-wifi/src/dhd/linux/dhd-cdc-sdmmc-gpl-2.6.35/dhd_sdio.o > dhd_dump.text
    这样dhd_sdio.c的反汇编代码就保存在dhd_dump.txt里面(注:这个是android环境下的代码路径)啦,我们找到dhdsdio_htclk这个函数的所在位置(我只贴相关部分,还附带了我的注释,汇编的注释就是c啦,哈哈哈)

00000124 <dhdsdio_htclk>:
     124:   e3510000    cmp r1, #0  ; 0x0   ;r1=on
     128:   e92d4ff0    push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
     12c:   e1a04000    mov r4, r0  ;r4=r0=bus
     130:   e24dd024    sub sp, sp, #36 ; 0x24
     134:   e1a07002    mov r7, r2
     138:   e5905004    ldr r5, [r0, #4]    ; sdh = bus->sdh; r5=sdh    ;ok
     13c:   0a0000d5    beq 498 <dhdsdio_htclk+0x374>
     140:   e5902008    ldr r2, [r0, #8]    ; r0+8=bus->sih ; r2=bus->sih   ;ok sih's real address
     144:   e3041329    movw    r1, #17193  ; 0x4329        ;ok
     148:   e5d031d8    ldrb    r3, [r0, #472]  ;r3=r0+472=bus->alp_only ; r3 = clkreq = bus->alp_only = 0;
     14c:   e5920030    ldr r0, [r2, #48]   ;r0=r2+48=bus->sih->chip    ;XXXXXXX  NO
     150:   e3530000    cmp r3, #0  ; 0x0   ;clkreq = bus->alp_only ? SBSDIO_ALP_AVAIL_REQ : SBSDIO_HT_AVAIL_REQ;
     154:   13a03008    movne   r3, #8  ; 0x8
     158:   03a03010    moveq   r3, #16 ; 0x10
     15c:   e1500001    cmp r0, r1
     160:   1a000002    bne 170 <dhdsdio_htclk+0x4c>
     164:   e5922034    ldr r2, [r2, #52]   ;;r2+52=bus->sih->chiprev
     168:   e3520000    cmp r2, #0  ; 0x0
     16c:   03833001    orreq   r3, r3, #1  ; 0x1   ;clkreq |= SBSDIO_FORCE_ALP; r3=clkreq
     170:   e1a00005    mov r0, r5
     174:   e3a01001    mov r1, #1  ; 0x1
     178:   e59f23a8    ldr r2, [pc, #936]  ; 528 <dhdsdio_htclk+0x404>
     17c:   e28dc01c    add ip, sp, #28 ; 0x1c
     180:   e58dc000    str ip, [sp]
     184:   ebfffffe    bl  0 <bcmsdh_cfg_write>
       ......(后面省略一大段)
下面再贴出c的代码啦,别急喔,

static int
dhdsdio_htclk(dhd_bus_t *bus, bool on, bool pendok)
{
    int err;
    uint8 clkctl, clkreq, devctl;
    bcmsdh_info_t *sdh;

    DHD_TRACE(("%s: Enter\n", __FUNCTION__));

#if defined(OOB_INTR_ONLY)
    pendok = FALSE;
#endif
    clkctl = 0;
    sdh = bus->sdh;


    if (on) {
        /* Request HT Avail */
        clkreq = bus->alp_only ? SBSDIO_ALP_AVAIL_REQ : SBSDIO_HT_AVAIL_REQ;

        if ((bus->sih->chip == BCM4329_CHIP_ID) && (bus->sih->chiprev == 0))
            clkreq |= SBSDIO_FORCE_ALP;




        bcmsdh_cfg_write(sdh, SDIO_FUNC_1, SBSDIO_FUNC1_CHIPCLKCSR, clkreq, &err);
        if (err) {
            DHD_ERROR(("%s: HT Avail request error: %d\n", __FUNCTION__, err));
            return BCME_ERROR;
        }
    ........(下面省略一大段)

由
PC is at dhdsdio_htclk+0x28/0x438 [dhd]
可知问题出在 从dhdsdio_htclk+0x28的代码处,由反汇编代码知dhdsdio_htclk在124位置处,加上0x28的话,就是0x14c处,我们找到0x14c对应的汇编代码

 14c:   e5920030    ldr r0, [r2, #48]   ;r0=r2+48=bus->sih->chip    ;XXXXXXX  NO

对于这段汇编代码,我在上面已经大概做出注释了,

    140:   e5902008    ldr r2, [r0, #8]    ; r0+8=bus->sih ; r2=bus->sih   ;ok sih's real address
由上一行汇编得知r2保存的是bus->sih的地址,r2偏移48那就是sih中的chip成员啦,可以给出sih的结构定义,如下

typedef struct dhd_bus {
    dhd_pub_t   *dhd;

    bcmsdh_info_t   *sdh;           /* Handle for BCMSDH calls */
    si_t        *sih;           /* Handle for SI calls */
    char        *vars;          /* Variables (from CIS and/or other) */
    ...... dhd_bus的定义,下面省略,只需关注sih这个成员变量
接着来看看sih的定义(即si_t)

struct si_pub {
    uint    socitype;       
    
    uint    bustype;     
    uint    buscoretype;
    uint    buscorerev; 
    uint    buscoreidx;
    int ccrev;       
    uint32  cccaps;
    int pmurev;       
    uint32  pmucaps;
    uint    boardtype;      
    uint    boardvendor;
    uint    boardflags;
    uint    chip;
    uint    chiprev;     
    uint    chippkg; 
    uint32  chipst;   
    bool    issim;    
    uint    socirev;   
    bool    pci_pr32414;
};
    
#if defined(WLC_HIGH) && !defined(WLC_LOW)
typedef struct si_pub si_t;
#else
typedef const struct si_pub si_t;
#endif

这样就方便看汇编啦,

从上面的分析可知,我们的代码是在读取r2+48(即r2+0x30)这个地址所对应的值,然后保存到r0中的时候出错的,

下面来验证我上面的分析。

-------------------------------------------------------验证---------------------------------------------------------

[ 231.043450] r10: 35c61ef0 r9 : 9ae40000 r8 : 00000001
[ 231.048681] r7 : 00000000 r6 : 00000000 r5 : 9c096000 r4 : 9c09f000
[ 231.055217] r3 : 00000000 r2 : 9c0d5000 r1 : 00004329 r0 : 9c09f000
oops提供的信息中包含了各个寄存器的值,让我们来看看r2,r2=0x9c0d5000,

那么r2+0x30=0x9c0d5030

好了,我们知道是在读取0x9c0d5030这个地址处的值,然后保存到r0的时候出现oops的,那么到底是读取的时候出错了,还是保存的时候出错了呢,

下面我们再来看一句可以验证我们想法的log信息,那就是oops的第一句,如下

Unable to handle kernel paging request at virtual address 9c0d5030
    注意看这个地址,,注意看最后的这个地址啊,,,,,,9c0d5030,哇,,好熟悉啊,不就是我们上面算出来的值么,,,,怎么验证了吧,是在读取这个地址的值的时候出错的。。。瓦咔咔,,,分析出来了,,


------------------------------------------------------后续--------------------------------------------------------

    上面好像一片和谐的景象啊,,结果有了,哈哈哈,可是不要高兴的太早喔,,结果是有了,可是该怎么解决呢,,毕竟我们分析问题的目的就是为了解决问题啊。。

单从该问题来说,我觉得可能是因为sih这个变量已经被deatch了,但是还没有验证,问题比较偶现,,唉,,最烦偶现的bug了,,

    其实写这篇文章的目的也主要是为了讲述怎么从oops信息中去查找对应c代码中的错误行的,在linux内核调试中还是很有用的。

    

Unable to handle kernel paging request at virtual address <pre name="code" class="cpp">9c0d5030

   

    其实对于这句话我还是没有能够理解到底是怎么了,怎么会出现这种错误,

    如果哪位朋友对这个比较了解的话,希望能不吝赐教,多多回帖帮我解惑,再此先感谢了。

ps: 解答上面的问题

不能访问的内核虚地址为45685516,内核中一般可访问的地址都是以0xCXXXXXXX开头的地址。



//---------------------------------------------------------------------------------------------------------------------------------------------------------------------

Oops: 0002 [#1]

这里面,0002表示Oops的错误代码(写错误,发生在内核空间),#1表示这个错误发生一次。

Oops的错误代码根据错误的原因会有不同的定义,本文中的例子可以参考下面的定义(如果发现自己遇到的Oops和下面无法对应的话,最好去内核代码里查找):

 * error_code:

 *      bit 0 == 0 means no page found, 1 means protection fault

 *      bit 1 == 0 means read, 1 means write

 *      bit 2 == 0 means kernel, 1 means user-mode

 *      bit 3 == 0 means data, 1 means instruction


Linux内核崩溃(kernel panic)时,如何快速定位问题代码?5个实用技巧分享 本文分享了5个实用技巧,帮助开发者在Linux内核崩溃(kernel panic)时快速定位问题代码。从解读panic日志、使用addr2line工具、分析调用栈到利用kdump获取内存转储,这些方法能有效提升调试效率,适用于服务器运维和嵌入式开发场景。 阅读详情

相关推荐

wifi ap6212驱动移植及调试分析技术笔记

这次帮客户调试wifi模块ap6212模块( BCM43438),由于硬件设计的问题,导致出现了各种驱动加载报错信息,而且网上很少这些报错信息,这才让人头疼,只好慢慢去摸索。本次是基于imx6平台进行调试,在imx6dl和imx6ul两个型号都调试成功。 驱动加载 将驱动加载到内核里,我没有将wifi编译成模块.ko,如果成功加载会打印以下信息。 dhd_module_init in Power-up adapter 'DHD generic adapter' - irq 50 [flags 1044],

qq_45147279的博客 1万+

linux 调试用到知识点

ubuntu 崩溃,进入grub解救: 内存不够导致系统崩溃,进入不了linux系统(grub rescure) 根据已有ramdisk镜像修改/替换ramdisk部分内容的方法:  1:unzip the image mv ./ramdisk.img ./ramdisk.img.gz gunzip ./ramdisk.img.gz 2:restore the image

shichaog的专栏 4020

iOS之深入解析Runtime的objc_msgSend“慢速查找”底层原理

CacheLookup 快速查找 objc_msgSend 通过汇编快速查找方法缓存,如果能找到则调用 TailCallCachedImp 直接将方法缓存起来然后进行调用,如果查找不到就跳到 CheckMiss ,然后走慢速查找流程。该文主要分析 objc_msgSend 慢速查找流程。 objc_msgSend 的快速查找请参考之前的文章:iOS之深入解析Runtime的objc_msgSend“快速查找”底层原理。 __objc_msgSend_uncached 慢速查找 CheckMiss 源码

╰つ栺尖篴夢ゞ 3万+

一个内核 Oops 问题的分析及解决

说了这么多,那么到底是不是呢,验证一下就知道了。关闭上述选项,重新编译内核,之后再编译exfat,查看汇编,发现偏移回到了776。Yes,问题就是这里了。 最近在调试设备时,遇到了一个偶发的开机死机问题。通过查看输出日志,发现内核报告了oops错误,如下所示(中间省略了部分日志,以......代替): Unable to handle kernel NULL pointer dereference at virtual address 0000000c pgd = cdd90000 [000000

Free雅轩的博客 2514

Android-S无线模块前瞻

WiFi - mainlane非强制 S 采用反射的方法直接加载wifiservice,直接hook在systemserver上,无编译依赖。gms可以动态替换wifi服务。 R 采用直接启动service的方式,wifiservice仍然map在systemserver上。 WiFi - 11ad接口支持 11ad被wifi联盟商业化为WIGIG,提供短距的60GHZ载波,理论速度为当前5G 11ac的6倍。市面上基本没有手机支持,需要独立的芯片支撑此功能。 传输距离为3m以内,外界d.

头铁的伦的博客 1043

等保2.0下可信验证的动态实现与合规实践

本文深入解读等保2.0标准中的“可信验证”要求,并重点探讨其动态实现与合规实践。文章阐述了从可信根、信任链到动态验证的核心概念,拆解了不同安全等级的实施差异,并提供了从硬件选型、软件赋能到平台集成的四步落地指南。通过行业案例与避坑心得,为构建覆盖计算环境、区域边界、通信网络和安全管理中心的全链条可信防御体系提供了实用参考。

d3e4f的博客 827

linux 内核出现 oops 如何调试

正儿八经上了半年的班了,也接触linux驱动几个月了,不过今天之前还是不会调试。今天也还是没有彻底学会。这篇博客主要是把今天的收获记录下来,方便以后参考。 我的内核版本是:4.9.88 我在3.14.52里面也实验过。 先贴我内核打印的错误信息: Unable to handle kernel NULL pointer dereference at virtual addre...

a3121772305的博客 3838

【通信原理 入坑之路】—— 详解IQ调制以及星座图原理

文章目录一. IQ调制与解调的原理与过程二.PSK(相移键控)和IQ调制的关系:2.1 用IQ调制实现QPSK调制 一. IQ调制与解调的原理与过程 IQ调制的定义是:“IQ调制就是数据分为两路,分别进行载波调制,两路载波相互正交。I是in-phase(同相), q是 quadrature(正交)” 我们通过下面的示意图介绍IQ调制的过程: 首先,信号分成两路:I路和Q路(为了方便理解我们把这两...

凝望,划过星空的博客 11万+

Android oops 分析

其实,它和上面的解释也没什么本质的差别,只不过说话的主角变成了 Linux。当某些比较致命的问题出现时,我们的 Linux 内核也会抱歉的对我们说:“哎呦(Oops),对不起,我把事情搞砸了”。当出了点小事故,或者做了比较尴尬的事之后,你可以说 "Oops",翻译成中国话就叫做 “哎呦”。把vmlinux符号文件拷贝到Android源码路径 android/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/ 下。

608

STM32duino LSM6DSO驱动库:低功耗IMU工程化实践

惯性测量单元(IMU)是智能终端与工业设备实现运动感知的核心传感器,其性能关键在于数据精度、实时响应与系统功耗的协同优化。LSM6DSO作为集成加速度计与陀螺仪的六轴MEMS器件,依托片上有限状态机(FSM)和机器学习核心(MLC),支持自由落体检测、计步器、6D方向识别等硬件自治功能,显著降低主控CPU负载。在STM32平台下,通过深度耦合HAL/LL库、显式引脚管理、DMA加速SPI传输及EXTI中断协同,可实现亚毫秒级事件响应与微安级待机功耗。本文聚焦STM32duino生态中LSM6DSO驱动的工程

weixin_36304957的博客 551

前端零代码丨UIOTOS + NodeRed:无代码搭建工控上位机的绝配组合!

用户类型价值硬件产品商软硬一体方案,无代码GUI上位机成新卖点软件服务商售前原型演示利器,交付成本降低至1/3平台开发商融合无代码技术,同质化竞争中脱颖而出🚀 总结UIOTOS的前端零代码设计(页面嵌套、属性继承、节点连线)与NodeRed的后端流程自动化,堪称工控与IoT开发的黄金组合。无论是串口通信、SCADA监控还是业务管理,均能实现“无代码交付”,真正让前端不求人,硬件交互触手可及!探索更多案例:UIOTOS官网在线体验。

2502_91192798的博客 757

从‘污染’标记到模块签名:解读Linux内核Oops信息里的那些‘小秘密’

本文深入解析Linux内核Oops日志中的污染标记和模块签名信息,揭示如何通过这些‘小秘密’诊断内核崩溃原因。从污染标记的含义到模块依赖分析,再到系统恢复实战,提供了一套完整的诊断指南,帮助运维人员快速定位和解决内核问题。

weixin_42699679的博客 391

基于 STM32 的智慧农业温室控制系统设计与实现

本文提出一种基于 STM32 微控制器的智慧农业温室控制系统设计方案,通过集成多类型环境传感器、执行机构及无线通信模块,实现对温室内温湿度、光照、土壤湿度等参数的实时监测与自动调控。文中详细阐述硬件选型、电路连接及软件实现流程,并附关键代码示例,为智慧农业领域提供低成本、高可靠性的温室控制解决方案。

weixin_42300449的博客 1923

call trace定位方法之一

calltrace是内核Oops问题的一部分,它是内核在发生错误时输出的一段调用栈信息,用于帮助开发人员定位问题。calltrace一般都是软件导致的问题。calltrace是提醒出现这个问题的风险性,而不是等出现这个问题才报calltrace,所以并不是所有的calltrace都会导致系统挂死。导致calltrace的原因有很多,常见的有:踩空指针,访问不存在的地址空间,中断异常等。addr2line -r tpm_tis_spi.ko 0x32c(最后的参数就是算出来的实际的符号的地址)

m0_61269311的博客 8970

自私兽群优化器(SHO)详解:从生物本能到智能优化

自私兽群优化器(SHO)是一种受动物群体自私行为启发的智能优化算法。该算法模拟动物在捕食威胁下的两种行为:聚集行为(全局搜索)和自私行为(局部搜索),将优化问题的解空间映射为生存环境,候选解视为猎物个体。SHO通过安全性评估将猎物分为安全、危险和高危三类,分别采用不同的位置更新策略,并引入捕食者角色增加选择压力。相比传统优化算法,SHO具有无需梯度信息、自适应平衡探索与开发、参数简单等优势,特别适合高维复杂和多模态优化问题。算法通过马尔可夫链理论保证收敛性,已在工程设计和数据挖掘等领域展现出良好性能。

qq_42212808的博客 196

Oracle EBS AP 应付模块核心实现逻辑(极简骨架 + 分层拆解 + 业务流转 + 分录 + 核心表)

Oracle EBS AP应付模块采用四层逻辑架构:1)主数据层统一管控供应商基础信息;2)发票负债层通过三单匹配校验生成应付账款;3)付款核销层实现负债冲减;4)SLA层自动生成财务凭证。核心流程包括发票验证(匹配PO/收货单)、付款核销(全额/部分冲账)、会计分录自动生成(通过SLA引擎)。模块严格遵循"无匹配不负债、无验证不入账"原则,与采购、库存等模块深度集成,实现从供应商创建到付款核销的完整业务闭环,确保应付账款准确性和审计追溯能力。

金牌架构师 440

OOp学习的记录

https://blog.youkuaiyun.com/android_huber/article/details/7580513 http://www.cnblogs.com/clover-toeic/p/3755401.html

yudelian的博客 284

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

别慌!手把手教你读懂Linux内核的‘临终遗言’(oops信息实战解析)

本文详细解析Linux内核崩溃时的Oops信息,提供从错误定位到源码分析的实战指南。通过工具使用和案例分析,帮助开发者快速诊断NULL指针解引用等常见问题,并分享预防系统崩溃的有效措施,提升Linux系统稳定性。

weixin_28730353的博客 93

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

AFL(American Fuzzy Lop)源码详细解读(7)

AFL(American Fuzzy Lop)源码详细解读 LLVM 部分源码分析解读

weixin_50972562的博客 385

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

jdk源码解析(一)

1、先说一下源码解析的过程:JDK-->JRE-->JVM(以openJDK代替) 注意:这里要了解jdk和jre和jvm他们分别是什么?以及他们的关系才可以继续。这里先上一章从网上下载的关系图方便理解 2、笔者本地的jdk是oraclejdk,jvm所在位置就是安装的jdk。jdk下jre下bin下server下的jvm.dll。也就是F:\Java\jdk\jdk1.7.0

敬业小码哥的博客 2万+

Linux 内核 Call Trace 完全解析指南

🔧从原理到实战,掌握内核崩溃问题的诊断与解决📋 目录速览图片🎯 什么是 Call Trace定义Call Trace(调用栈跟踪)是 Linux 内核在发生错误、警告或崩溃时,打印出的函数调用链路信息。它显示了程序执行到出错点的完整路径。为什么会出现 Call Trace?图片Call Trace 的作用图片📝 Call Trace 的类型图片特征:内核崩溃,系统停止运行图片3. Warning特征:内核警告,但继续运行图片。

xp5120606a的博客 192

jdk源码解析之解析过程(一)

原文链接:https://blog.csdn...

csdn_hklm的博客 468
上一篇: 关于oops定位处理的一些收集整理,
下一篇: Android HAL层实现与调用
huber
博客等级 码龄15年 79粉丝 24原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值