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

Sebastian Huber sebastian.huber at
Tue Jul 29 17:41:27 UTC 2014

On 07/29/2014 04:26 PM, Fabrício de Novaes Kucinskis wrote:
> Hello Sebastian, thanks again for your help.
> My example worked when using CONFIGURE_UNLIMITED_OBJECTS and
> However, I don't understand why a simple example like this needs such
> configuration to run - especially when it works on the previous release.

Its not a simple example, it uses the C++ new operator which may throw 
exceptions.  If you use the placement new, then it is simple. The 
workspace size estimate is much more precise in RTEMS 4.11 compared to 
previous releases which overestimated.  So it was mere luck that it 
worked before.

> There's no queue, no additional task, no region, no nothing.
> That's the simplest configuration on which the problem occurs:
> 	#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".

If you look at <rtems/score/interr.h> the 22 gives you 
INTERNAL_ERROR_GXX_MUTEX_INIT_FAILED (see also rtems_internal_error_text()).

> 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)

We have also:

Configuration Changes

  * More accurate workspace size estimate.

> 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?

You have to account for C++ runtime resources.

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
PGP     : Public key available on request.

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

More information about the users mailing list