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

Fabrício de Novaes Kucinskis fabricio at dea.inpe.br
Tue Jul 29 14:26:41 UTC 2014


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.

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



More information about the users mailing list