About HEAP error

[Gedare Bloom]

On Wed, Mar 3, 2021 at 9:28 AM Joel Sherrill <joel.sherrill at gmail.com> wrote:
>
>
>
> On Wed, Mar 3, 2021 at 9:50 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Wed, Mar 3, 2021 at 12:08 AM Richi Dubey <richidubey at gmail.com> wrote:
>> >
>> > What's the element written after the free? I set a watch at the exact block location, but it doesn't work:
>> >
>> > Hardware watchpoint 7: *0x202ba8
>> > (gdb) watch *0x206fec
>> > Hardware watchpoint 8: *0x206fec
>> That's just the first byte in the block. If you can figure out which
>> bytes/words in the block get accessed that would help you.
>
>
> What about watch *(unsigned int)*  0x202ba8?
>
> Won't that look at more bytes?

And this is just the first byte of the workspace area.

>
> In case you do need to look at more bytes in the fence...
> breaking at _Terminate and doing a back trace will give
> you the exact line the error is raised from. You can then set a
> breakpoint at that on the next line and look at local variables.
> The corruption may be in the fence somewhere beyond the
> first 32-bits.
>
> Sometimes it is easy to binary search for an issue like this
> on a simulator. But with a watchpoint, you should be able to
> determine the precise word which is corrupted in the fence
> and break on that write.
>
> --joel
>>
>>
>> > (gdb) c
>> > Continuing.
>> >
>> > Thread 1 hit Breakpoint 6, Init (argument=2107944) at /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:26
>> > 26  TEST_BEGIN();
>> > (gdb)
>> > Continuing.
>> >
>> > Thread 1 hit Breakpoint 5, _Terminate (the_source=RTEMS_FATAL_SOURCE_HEAP, the_error=2125180) at /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/interr.c:38
>> > 38  _User_extensions_Fatal( the_source, the_error );
>> > (gdb)
>> > Continuing.
>> >
>> > Thread 1 hit Breakpoint 4, bsp_reset () at /home/richi/quick-start/LatestStrong/src/rtems/c/src/lib/libbsp/arm/realview-pbx-a9/../../../../../../bsps/arm/realview-pbx-a9/start/bspreset.c:19
>> > 19  volatile uint32_t *sys_lock = (volatile uint32_t *) 0x10000020;
>> > (gdb)
>> >
>> > On Wed, Mar 3, 2021 at 12:31 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>> >>
>> >> On 02/03/2021 05:44, Richi Dubey wrote:
>> >>
>> >> >
>> >> > (gdb) p *(Heap_Error_context*)(0x00206d7c)
>> >> > $5 = {
>> >> >   heap = 0x202ba8 <_Workspace_Area>,
>> >> >   block = 0x206fec,
>> >> >   reason = HEAP_ERROR_FREE_PATTERN
>> >> > }
>> >>
>> >> If it is always the same address, then you can set a watch point to an
>> >> element which is written after the free to catch the function which
>> >> writes into this area.
>> >>
>> >> --
>> >> embedded brains GmbH
>> >> Herr Sebastian HUBER
>> >> Dornierstr. 4
>> >> 82178 Puchheim
>> >> Germany
>> >> email: sebastian.huber at embedded-brains.de
>> >> phone: +49-89-18 94 741 - 16
>> >> fax:   +49-89-18 94 741 - 08
>> >>
>> >> Registergericht: Amtsgericht München
>> >> Registernummer: HRB 157899
>> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> >> Unsere Datenschutzerklärung finden Sie hier:
>> >> https://embedded-brains.de/datenschutzerklaerung/
>> >>
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel