> > 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.
Good point, the corruption has already happened earlier, and yes its quite early : ... #13 0x0010860e in rtems_task_create (name=1413558560, initial_priority=1, stack_size=4096, initial_modes=0, attribute_set=0, id=0x202444 <Task_id+4>) at /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/rtems/src/taskcreate.c:84 #14 0x001015fa in Init (argument=2107944) at /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../testsuites/sptests/sp02/init.c:101 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. > Yes, or maybe I would try to manually put a watchpoint at all the 32 bytes starting 0x202ba8 and see if it works. 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. Yes! Maybe the scheduler access a variable outside its bound (maybe an array element outside its array size), but if that is true, there should be a lot more failure with HEAP_ERROR. I would still give it a look. Thanks again for your help. On Fri, Mar 5, 2021 at 7:01 PM Joel Sherrill <j...@rtems.org> wrote: > > > On Thu, Mar 4, 2021, 11:31 PM Richi Dubey <richidu...@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 <ged...@rtems.org> wrote: >> >>> 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