Helo,
I need help to capture a bad memory access.
When leaving a task, I end up with a "ressource" error in "__free_threadlocal_timer"
using the debug view in XTC14.4.1, I can see that the table containing the resource timer for the task is corrupted with a Zero at the expected adress...
I try to capture which program/instructruction is making this and struggling with the debugger ..
how can I capture a write in this timer table (32bytes) knowing its address (say 0x5D250) ?
I ve tried the add watchpoint c/c++ but not sure what to write in the setup window
many thanks in advance
fabriceo
HELP required watchpoint breakpoint setup (XTC14.4.1)
-
- Respected Member
- Posts: 265
- Joined: Mon Jan 08, 2018 4:14 pm
HELP required watchpoint breakpoint setup (XTC14.4.1)
You do not have the required permissions to view the files attached to this post.
-
- Active Member
- Posts: 34
- Joined: Mon Nov 21, 2022 5:38 pm
Using XGDB you should be able to add a breakpoint using watch *(unsigned int*)0x5D250 this should trigger a break if a write at the address occours
-
- Respected Member
- Posts: 265
- Joined: Mon Jan 08, 2018 4:14 pm
Thank you lmariotti ! I didn't know that it was possible to use a C or C++ like syntax. I just tried it. Thanks
but then I could nt capture anything.
Then I suspected that maybe my program is clean and something else happen.
printing the 8 values of the local timers table at the beginning of the task entry, I realized that sometime some of them were Zero instead of the usual resource value 101/201/301... so of course if they are zero at start, they will create a resource exception when existing the task...
I then I noticed that at the next cycle, it was using other timers ressource reference, because some where lost because not freed properly...
seems the __start_core routine doesn't have a problem when using the "getr", even if there is no more resource available ... and the __free_threadlocal_timer doesn't check if the resource was properly allocated...
and then I found the reason , the way I m allocating and deallocating the tasks with the "par" statement has a problem. thats it.
need to find a solution, but ok.
thanks
but then I could nt capture anything.
Then I suspected that maybe my program is clean and something else happen.
printing the 8 values of the local timers table at the beginning of the task entry, I realized that sometime some of them were Zero instead of the usual resource value 101/201/301... so of course if they are zero at start, they will create a resource exception when existing the task...
I then I noticed that at the next cycle, it was using other timers ressource reference, because some where lost because not freed properly...
seems the __start_core routine doesn't have a problem when using the "getr", even if there is no more resource available ... and the __free_threadlocal_timer doesn't check if the resource was properly allocated...
and then I found the reason , the way I m allocating and deallocating the tasks with the "par" statement has a problem. thats it.
need to find a solution, but ok.
thanks