About HEAP error

[Richi Dubey]

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.

Also, setting a watchpoint doesn't help:

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/1cb7c2ad/attachment-0001.html>