On Wed, Mar 3, 2021 at 9:49 AM Gedare Bloom <ged...@rtems.org> wrote:
>
> On Wed, Mar 3, 2021 at 9:28 AM Joel Sherrill <joel.sherr...@gmail.com> wrote:
> >
> >
> >
> > On Wed, Mar 3, 2021 at 9:50 AM Gedare Bloom <ged...@rtems.org> wrote:
> >>
> >> On Wed, Mar 3, 2021 at 12:08 AM Richi Dubey <richidu...@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.hu...@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.hu...@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@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> _______________________________________________
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
