Re: Crash deep in heap allocation for rtems_region_get_segment() call

[Matthew J Fletcher]

Gedare / Sebastian,

Thank you for your advice, --enable-rtems-debug and then using malloc_walk()
helps to investigate the issue.

On 7 March 2018 at 14:47, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Matthew,
>
> it is very likely not a bug in the heap code. It is probably a use after
> free or heap block overwrite. You can use the --enable-rtems-debug
> configuration option to enable a heap protections which helps to catch
> these application errors.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> 
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>


-- 

regards
---
Matthew J Fletcher
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Crash deep in heap allocation for rtems_region_get_segment() call

[Sebastian Huber]

Hello Matthew,

it is very likely not a bug in the heap code. It is probably a use after 
free or heap block overwrite. You can use the --enable-rtems-debug 
configuration option to enable a heap protections which helps to catch 
these application errors.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Crash deep in heap allocation for rtems_region_get_segment() call

[Gedare Bloom]

On Tue, Mar 6, 2018 at 1:12 PM, Matthew J Fletcher  wrote:
> Hi
>
> So the current block is 0x70b0bef8 with a size_and_flag of 257, block->next
> is 0x70b0c9f8 with a size_and_flag of 381, block->prev is 0x701615b8
> with a size_and_flag of 0.
>
> I note that the 'prev' and the 'free_list_anchor' are the same, as is the
> 'heap' pointer, not sure if thats normal ?
>
I don't know the answer to this question, but I suspect it is normal
and that the current block is the first unused block, with size 256.

The block_next is unused with size 3,444,480 or about 3.2 MiB as would
be expected. As far as I can tell, there's not a good reason for the
crash at this point, so I'm baffled. The memory accesses appear to be
within the expected regions.


>
> I would normally presume this is a BSP / my_platform issue, but my linker
> script has the following, which looks fine.
>
>  "SDRAM  : ORIGIN = 0x7000, LENGTH = 0x0100"
>  "RTEMS_AREA : ORIGIN = ORIGIN (SDRAM), LENGTH = 9216k"  // APP_BSS and
> APP_HEAP are after this, so 9216k is somewhat arbitrary.
>
>
>
> regards
> ---
> Matthew J Fletcher
>
>
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Crash deep in heap allocation for rtems_region_get_segment() call

[Matthew J Fletcher]

Hi

So the current block is 0x70b0bef8 with a size_and_flag of 257, block->next
is 0x70b0c9f8 with a size_and_flag of 381, block->prev is 0x701615b8
with a size_and_flag of 0.

I note that the 'prev' and the 'free_list_anchor' are the same, as is the
'heap' pointer, not sure if thats normal ?


I would normally presume this is a BSP / my_platform issue, but my linker
script has the following, which looks fine.

 "SDRAM  : ORIGIN = 0x7000, LENGTH = 0x0100"
 "RTEMS_AREA : ORIGIN = ORIGIN (SDRAM), LENGTH = 9216k"  // APP_BSS and
APP_HEAP are after this, so 9216k is somewhat arbitrary.



regards
---
Matthew J Fletcher
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Crash deep in heap allocation for rtems_region_get_segment() call

[Gedare Bloom]

On Tue, Mar 6, 2018 at 11:25 AM, Matthew J Fletcher  wrote:
> Hi,
>
> I've been investigating an interesting but reproducible crash deep in the
> heap allocator, any help much appreciated.
>
>
> This is the callstack..
>
> _Heap_Is_prev_used() at heapimpl.h:510 0x700ebb8e
> _Heap_Is_used() at heapimpl.h:517 0x700ebb8a
> _Heap_Block_split() at heap.c:336 0x700ebb7c
> _Heap_Block_allocate_from_begin() at heap.c:371 0x700ebbf0
> _Heap_Block_allocate() at heap.c:461 0x700ebdb6
> _Heap_Allocate_aligned_with_boundary() at heapallocate.c:262 0x700ebf0e
> _Heap_Allocate() at heapimpl.h:137 0x700ea4a4
> _Region_Allocate_segment() at regionimpl.h:108 0x700ea4a4
> rtems_region_get_segment() at regiongetsegment.c:79 0x700ea4a4
>
>
> RTEMS_INLINE_ROUTINE bool _Heap_Is_used(
>   const Heap_Block *block
> )
> {
>   const Heap_Block *const next_block =
> _Heap_Block_at( block, _Heap_Block_size( block ) );
>
>   return _Heap_Is_prev_used( next_block );
> }
>
> so this is the routine above the crash,. in the debugger i can see that
> 'block' is at a valid address, but 'next_block' is "optimized out" and gdb
> wont show it (rtems is already re-compiled with -0g)
>
You should be able to calculate next_block given that you know what
block is, that might help you.

>
> RTEMS_INLINE_ROUTINE bool _Heap_Is_prev_used( const Heap_Block *block )
> {
>   return block->size_and_flag & HEAP_PREV_BLOCK_USED;
> }
>
> i presume that in this crashing routine, block must be invalid.
>
> There is still 3.4mb left on the heap at this point (from the stats pointer
> information), its not like this is an early startup crash, from the
> Heap_Statistics;
>
> lifetime_allocated 788736
> lifetime_freed 40704
> size 4194048
> free_size 3445504
> min_free_size 3445504
> free_blocks 3
> max_free_blocks 5
> used_blocks 128
> max_search 4
> searches 289
> allocs 267
> failed_allocs 0
> frees 130
> resizes 0
>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users