• State Verified Answer
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 2763 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 296897
Options

OS Faulting instruction address (r15/pc): 0x000174c8

Learner

Hello,

I am getting the following error in Segger Embedded Studio v5.60

SEGGER Embedded Studio for ARM
Release 5.60  Build 2021081102.47262
Nordic Edition
Windows x64

* buffer overflow detected *
[00:03:32.312,866] <err> os: r0/a1: 0x00000003 r1/a2: 0xe000ed00 r2/a3: 0x00000001
[00:03:32.312,866] <err> os: r3/a4: 0x00000050 r12/ip: 0x00000013 r14/lr: 0x00036363
[00:03:32.312,866] <err> os: xpsr: 0x61000000
[00:03:32.312,896] <err> os: Faulting instruction address (r15/pc): 0x000174c8
[00:03:32.312,896] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:03:32.312,896] <err> os: Current thread: 0x20001f30 (sysworkq)
[00:03:32.551,361]<err> os: Halting system

I located the line of code where this crash is occurring using addr2line command and it is in libc-hooks.c 

toolchain\opt\bin\arm-none-eabi-addr2line -e C:\Sandbox\HomeBeacon_dev_sb\build_nrf52833dk_nrf52833_v1_4_2_dbg\zephyr\zephyr.elf -a 0x000174c8   

0x000174c8
C:/Zypher/v1.7.0/zephyr/lib/libc/newlib/libc-hooks.c:327

The first error shown above in red is * buffer overflow detected *. Which buffer is this?

I have a strong suspicion the root cause is lying within my code. It would have been very helpful if the error message  <err> os: Faulting instruction address (r15/pc): 0x000174c8 

pointed to the actual line of code within my application rather than somewhere in the libc library.

Can someone please help me debug this and get to the root cause of this problem?

Thank you.

Kind regards

Mohamed

Parents
  • 0

    Hi Mohamed,

    I also suspect that the problem lies with your code; it's not unlikely that it's just a C programming error, where you're writing past the bounds of an array (sorry if this sounds obvious).

    Could you run your code with a debugger, and take a look at your stack frame when it crashes? You'll see the function that was calling into libc-hooks.

    We don't have the capacity to help with debugging every kind of C problem, but I hope this gets you started for now.

    Let me know if there's more you're wondering about!

    Best regards,

    Raoul Pathak

  • 0 in reply to Raoul

    Hi Raoul,

    Thank you for your response.

    As suspected, the root cause of the crash was a stray array index getting out of range. It is fixed now.

    Raoul said:
    Could you run your code with a debugger, and take a look at your stack frame when it crashes? You'll see the function that was calling into libc-hooks.

    I think I did try to use the Call stack in the debugger but it did not help. SES debugger did not show the complete call stack all the way back to my application code. 

    My point was the error message could have been more helpful by pointing to an address in the application code.

    Kind regards

    Mohamed

Reply
  • 0 in reply to Raoul

    Hi Raoul,

    Thank you for your response.

    As suspected, the root cause of the crash was a stray array index getting out of range. It is fixed now.

    Raoul said:
    Could you run your code with a debugger, and take a look at your stack frame when it crashes? You'll see the function that was calling into libc-hooks.

    I think I did try to use the Call stack in the debugger but it did not help. SES debugger did not show the complete call stack all the way back to my application code. 

    My point was the error message could have been more helpful by pointing to an address in the application code.

    Kind regards

    Mohamed

Children
Related
Terms of service