• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 755 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/DRA71: XDC.RUNTIME.MEMORY: How to configure a breakpoint there?

Christian N
Expert 1285 points
Part Number: DRA71
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Team

We are having an out of memory condition, as you can see below

[0][      8.901] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
[0][      8.901] [t=0xe1cd9b9f] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61
[0][    283.501] [t=0x0000001c:15aed3ed] xdc.runtime.Memory: ERROR: line 52: out of memory: heap=0x80062a08, size=72
[0][    283.501] xdc.runtime.Memory: line 52: out of memory: heap=0x80062a08, size=72
[0][    283.501] [t=0x0000001c:15b171ef] ti.sdo.ipc.MessageQ: ERROR: line 503: assertion failure: A_invalidMsg: Invalid message
[0][    283.502] ti.sdo.ipc.MessageQ: line 503: assertion failure: A_invalidMsg: Invalid message
[0][    283.502] xdc.runtime.Error.raise: terminating execution

We noticed that inserting a delay prior a function call it is harder to reproduce, so before increasing heap size we are trying to find the root cause

We are trying to debug it (CCS8 & ti-processor-sdk-rtos-automotive-dra7xx-evm-04.00.00.04) and it would be usefull to set a breakpoint in function that detects out of memory but we can't find it (xdc.runtime.Memory)

Could you help with that?

Regards

  • 0
    TI__Expert 5725 points
    Hi Christian,

    If you are looking to break when the error condition occurs, you can set a breakpoint in one of the error-related functions in the call stack. The actual error policy is defined by your application configuration, so this may not be a straightforward answer. Here are three areas you can try setting breakpoints:

    1. xdc.runtime.Memory is defined under <XDCTOOLS_ROOT>/packages/xdc/runtime/Memory.c. When there is an allocation error, it calls Error_raise, which maps to Error_raiseX to provide module, line, file info in addition to the actual error. This is a macro'd function name - the real name is xdc_runtime_Error_raiseX__E. This is defined in <XDCTOOLS_ROOT>/packages/xdc/runtime/Error.c. You can try setting a breakpoint here.

    2. From this, the application-specific policy function is called, which you may be able to find in your configuration-generated code (can search for xdc_runtime_Error_policyFxn__C, possibly in a folder in your application build space under configPkg/package/cfg/<appname>_<arch>.c). You can also set a breakpoint here.

    3. Finally, the policy function should eventually trigger the error and there is a hook defined. By default it is ti_sysbios_BIOS_errorRaiseHook__I, but perhaps the application has added some replacement hook implemented.

    Hopefully one of these helps. From there, you should be able to look at the call stack and see where the memory allocation attempt is failing.

    Thanks,
    Stephen
  • 0 in reply to Stephen Molfetta
    Expert 1285 points

    Hi Stephen

    1.Works for me.

    I noticed that echo disabled > /sys/kernel/debug/remoteproc/remoteproc0/recovery should be ran to avoid IPU reset and lost breakpoints

    Thanks a lot