cancel
Showing results for 
Search instead for 
Did you mean: 

The software breakdown when I pitch on Expand Variable List in variables node

0.Developer
Associate II

The process is as follows:

  • config the variables node ,choose the axf executable files
  • pitch on Expand Variable List
  • waiting for the file parsing,and then the software breakdown

0693W000000TdrbQAC.png

1 ACCEPTED SOLUTION

Accepted Solutions

Actually STM32CubeMonitor is running out of memory when parsing the executable file.

Indeed when parsing the file, our parser is retrieving a variable which is an array of 29605888 unsigned char.

When clicking on "Expand Variable list" checkbox, our parser is trying to retrieve the 29605888 adresses of the array elements.

This array variable retrieved by the arm debugger tool (on which our parser is relying) is located in "..\Utilities\malloc.c" file and names "mem2base":

(gdb) ptype mem2base
type = unsigned char [29605888]

This size is far too high for our parser capabilities then the crash occurs.

As a fix, we will need to limit in our parser the size of the array to expand such as it won't crash anymore when parsing such executable file.

Thanks for raising this issue, and stay tuned for upcoming fix release.

View solution in original post

6 REPLIES 6
Thierry
Senior

Hello 0.Developer,

Could you please provide your axf executable file ?

Thanks !

Of course~

See the attach file.

Always crashes at 74%~~:face_with_tears_of_joy:

Thanks for the file. Likely a bug, currently investigating why this specific file makes the STM32CubeMonitor crashed.

Actually STM32CubeMonitor is running out of memory when parsing the executable file.

Indeed when parsing the file, our parser is retrieving a variable which is an array of 29605888 unsigned char.

When clicking on "Expand Variable list" checkbox, our parser is trying to retrieve the 29605888 adresses of the array elements.

This array variable retrieved by the arm debugger tool (on which our parser is relying) is located in "..\Utilities\malloc.c" file and names "mem2base":

(gdb) ptype mem2base
type = unsigned char [29605888]

This size is far too high for our parser capabilities then the crash occurs.

As a fix, we will need to limit in our parser the size of the array to expand such as it won't crash anymore when parsing such executable file.

Thanks for raising this issue, and stay tuned for upcoming fix release.

Thanks for your explain, Thierry.

Looking forward to the fix release !