About HEAP error
Joel Sherrill
joel.sherrill at gmail.com
Wed Mar 3 16:28:07 UTC 2021
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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210303/0ed0bbe0/attachment.html>
More information about the devel
mailing list