RES: RES: Problem with simple 'new' operator when using RTEMS 4.11 for the SIS BSP

Joel Sherrill joel.sherrill at oarcorp.com
Tue Jul 29 15:01:11 UTC 2014



On July 29, 2014 10:26:41 AM EDT, "Fabrício de Novaes Kucinskis" <fabricio at dea.inpe.br> wrote:
>Hello Sebastian, thanks again for your help.
>
>My example worked when using CONFIGURE_UNLIMITED_OBJECTS and
>CONFIGURE_UNIFIED_WORK_AREAS. 
>
>However, I don't understand why a simple example like this needs such
>configuration to run - especially when it works on the previous
>release.
>There's no queue, no additional task, no region, no nothing.

You have light application requirements but the C++ libraries must be accounted for as well.

>
>That's the simplest configuration on which the problem occurs:
>
>	#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>	#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>	#define CONFIGURE_TERMIOS_DISABLED
>	#define CONFIGURE_MAXIMUM_TASKS 2 // just idle and init
>
>Just remembering, my (complete) example is the following:
>
>rtems_task Init (rtems_task_argument argument)
>{
>    int *var = new int[10];
>        
>    var[0] = 2;
>    printk("testing... %i", var[0]);
>}
>
>And the result - having SIS as BSP - is that Init is not achieved and
>_Terminate() indicates as arguments "source = INTERNAL_ERROR_CORE",
>"is_internal = true" and "the_error = 22".
> 
>Trying different configurations, I found that if I remove
>"CONFIGURE_TERMIOS_DISABLED", my example works - in this case, there's
>no
>need for unifying the work areas or to set the objects space as
>unlimited.
>
>What could be the relation between disabling termios and the heap
>available
>- again, in such a simple example - and why does it work on 4.10?
>
>Looking at the 4.11 release notes, two statements called my attention:
>	* "The work area initialization (RTEMS work space and C program
>heap) changed. Now a table based initialization is used."
>	* "The Termios interrupt write support invocation changed." (but I
>emphasize that I'm disabling termios)
>
>Could one of these changes have messed up with memory allocation for
>SPARC
>BSP's, or do I have to configure RTEMS in a different way now, even for
>the
>simplest code?
>
>One more time, thanks for the help and best regards,
>
>Fabrício.
>
>
>-----Mensagem original-----
>De: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de] 
>Enviada em: segunda-feira, 28 de julho de 2014 16:20
>Para: Fabrício de Novaes Kucinskis; 'RTEMS Users'
>Assunto: Re: RES: Problem with simple 'new' operator when using RTEMS
>4.11
>for the SIS BSP
>
>On 07/28/2014 08:43 PM, Fabrício de Novaes Kucinskis wrote:
>> The following example is enough to illustrate the problem I'm facing:
>>   
>> rtems_task Init(rtems_task_argument argument) {
>>      int *var = new int[10];
>>          
>>      var[0] = 2;
>>      printk("testing... %i", var[0]);
>> }
>>   
>> If 'var' is allocated on the stack ("int var[10]"), the program runs
>ok.
>> When using the 'new' operator (and hence using the heap), the 
>> execution doesn't achieve the Init task, stopping at some instruction
>
>> inside
>> _Thread_Start_multitasking() – that’s what I vaguely called ‘crash’ 
>> before, sorry for that.
>
>A constant error source is the RTEMS configuration, so it is always
>good to
>have self-contained example and not some code snippet. I would always
>set a
>break point to _Terminate(), since this gives you a good hint in most
>cases.
>
>You likely have not enough resources for the C++ basics, try to use
>
>#define CONFIGURE_UNLIMITED_OBJECTS
>#define CONFIGURE_UNIFIED_WORK_AREAS
>
>for an easy start.
>
>--
>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.huber at embedded-brains.de
>PGP     : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
>---
>Este email está limpo de vírus e malwares porque a proteção do avast!
>Antivírus está ativa.
>http://www.avast.com
>
>_______________________________________________
>users mailing list
>users at rtems.org
>http://lists.rtems.org/mailman/listinfo/users




More information about the users mailing list