_Heap_Initialize called twice, crashes second time around

[Matthew J Fletcher]

On 19 February 2013 15:21, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

> On 2/19/2013 9:16 AM, Gedare Bloom wrote:
>
>> Some BSPs also will unify the workspace and heap, in which case I
>> believe initialization only happens once.
>>
> This is an application time configure option.
>
> Some BSPs on hardware with non-contiguous address spaces
> may assign one to workspace and one to heap. Sebastian added
> that for the plethora of CPUs with on-chip RAM areas and off-chip
> and slower RAM.
>
> Most likely, there is a mistake in the memory map as you
> suggested in the previous email.
>
> There are some debug prints in bspgetworkarea and other places
> which can give hints but definitely check the address ranges passed
> to the two invocations, where you have reserved the stack you
> are initializing the system on, and your .bss section. Sounds like
> you have an overlap or are pointing to non-existent memory
>
> --joel
>
>  On Tue, Feb 19, 2013 at 10:15 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> Heap Initialize is reused to initialize the RTEMS workspace, and the C
>>> program heap. This is normal when the workspace and heap are separate
>>> (non-unified). Check that your workspace and heap are indeed distinct
>>> in your memory layout (linkcmds) and non-overlapping. Crashes can
>>> happen when they overlap or when the malloc heap pointer is bogus.
>>>
>>> -Gedare
>>>
>>> On Tue, Feb 19, 2013 at 7:05 AM, Matthew J Fletcher <amimjf at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am not passing any particularly non-standard configure options,
>>>> "--disable-cxx --disable-posix --disable-itron --enable-networking
>>>> --target=arm-rtemseabi4.11 --enable-rtemsbsp=rtl22xx_t".
>>>>
>>>> 1st callstack
>>>>
>>>> boot_card()
>>>> -> rtems_initialize_data_**structures()
>>>>    -> _Workspace_Handler_**initialization()
>>>>      -> _Heap_Initialize()
>>>>
>>>> 2nd callstack
>>>>
>>>> boot_card()
>>>> -> bootcard_bsp_libc_helper()
>>>>    -> bsp_libc_init()
>>>>      -> RTEMS_Malloc_Initalize()
>>>>        -> _Heap_Initalize()
>>>>
>>>> Is this BSP not configured quite right ?
>>>>
>>>>
>>>> regards
>>>> ---
>>>> Matthew J Fletcher
>>>>
>>>>
>>>> ______________________________**_________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/**listinfo/rtems-users<http://www.rtems.org/mailman/listinfo/rtems-users>
>>>>
>>>>  ______________________________**_________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/**listinfo/rtems-users<http://www.rtems.org/mailman/listinfo/rtems-users>
>>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>
Thanks for the tips, using the debugger i can see that the workspace is
setup as:

starting_address 0x81486ab0
size 0xffff

and the RTEMS heap:

starting address 0x81496aaf (so on by 0xffff)
size oxffff

that looks ok to me, interesting the actual reason for the crash is that
the Heap_Control structure is at 0xffffffffff, so we error when the first
variable is assigned to it.

It looks like this comes from RTEMS_Malloc_Heap in confdefs.h, so i've no
idea how it could be -1, i will step through the startup code and watch so
see where/if it gets stamped on.


regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130219/9f989289/attachment-0001.html>