About HEAP error

Fri Mar 5 13:31:22 UTC 2021

On Thu, Mar 4, 2021, 11:31 PM Richi Dubey <richidubey at gmail.com> wrote:

> Hi,
>
> Thanks to both of you for helping me out with this!
>
> When I backtrace on _Terminate: I get this:
>
> Init -> rtems_task_create -> ... -> _Heap_Allocate -> ...
> ->_Heap_Protection_check_free_block -> _Heap_Protection_block_error
> ->_Heap_Protection_block_error_default -> _Terminate
> (the_source=RTEMS_FATAL_SOURCE_HEAP, the_error=2125180). So I will try to
> debug this trace.
>

This is just the detection point. The allocate is doing a validity check
and something is wrong from an overwrite.

FWIW this is pretty early in the test I think.

> Also, setting a watchpoint doesn't help:
>

Look manually at say 32 bytes at that address at various points during the
program's execution. I think this is one where a binary search for the
corrupting action happens.

Is this using your scheduler as the default? If so, I'd be suspicious of
anything allocated for it and if you were riding outside an area allocated
for you.

>
> 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) watch *(unsigned int)*  0x202ba8
> Hardware watchpoint 13: *(unsigned int)*  0x202ba8
> (gdb) c
> 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 );
>
>
>
> On Wed, Mar 3, 2021 at 10:20 PM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Wed, Mar 3, 2021 at 9:49 AM Gedare Bloom <gedare at rtems.org> wrote:
>> >
>> > 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.
>> >
>> 4 bytes :)
>> > >
>> > > 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.
>> > >
>> In the case of heap corruption, the corruption is detected after it
>> already happened. Narrowing down when/where the corruption happens is
>> necessary. The next thing to do would be to examine the pattern that
>> triggers the violation, and see where it got modified. This might
>> provide a byte address to set a watch on.
>>
>> > > 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210305/58702a18/attachment.html>