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

[Fabrício de Novaes Kucinskis]

Hello Sebastian, and thanks for your answer.

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.

This happens when linking with RTEMS 4.11 for the SIS BSP. Using RTEMS 4.10
for the same BSP, this problem doesn't occur.

I have two suspicions:
1) [more likely] Some problem with my compiling environment that I
could not trace yet, or
2) Some change on the heap setup for the SPARC BSP between the
release 4.10 and the current head of the git repository. I noticed some
change on this aspect with the addition of a 'bsp_early_malloc' function
that didn't exist on 4.10, but I don't think an error like this wouldn't be
noticed previously.

Thanks again and best regards,

Fabrício.

Hi all,
I’ve recently installed RTEMS 4.11 from the git head and am facing a

strange

problem: whenever I use the ‘new’ operator for a C++ application, the
application crashes.

What do you mean with crash?

If, for instance, I have a printk instruction some lines before calling
‘new’ (as “int *a = new int[10];”), there is no output. It seems that the
addition of ‘new’ is forcing the link to some C++ library that is not ok
working well.

I would follow the printk() call and figure out why there is no output.

RTEMS 4.10 and 4.11 are installed in different computers).
I’m feeling dumb right now for not having any idea about what is going on.
Any tips?

It helps if you provide a self contained example that reproduces the
problem.
--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : [phone]
Fax : [phone]
E-Mail : <http://lists.rtems.org/mailman/listinfo/users> 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

[Sebastian Huber]

Post by Fabrício de Novaes Kucinskis
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 : [phone]
Fax : [phone]
E-Mail : sebastian.huber-L1vi/***@public.gmane.org
PGP : Public key available on request.

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

[Fabrício de Novaes Kucinskis]

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-L1vi/***@public.gmane.org]
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

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 : [phone]
Fax : [phone]
E-Mail : sebastian.huber-L1vi/***@public.gmane.org
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

[Joel Sherrill]

Post by Fabrício de Novaes Kucinskis
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.

Post by Fabrício de Novaes Kucinskis
#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
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?
* "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-----
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

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 : [phone]
Fax : [phone]
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
http://lists.rtems.org/mailman/listinfo/users

[Sebastian Huber]

Post by Fabrício de Novaes Kucinskis
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.

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.

Post by Fabrício de Novaes Kucinskis
There's no queue, no additional task, no region, no nothing.
#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
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()).

Post by Fabrício de Novaes Kucinskis
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?
* "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.

Post by Fabrício de Novaes Kucinskis
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 : [phone]
Fax : [phone]
E-Mail : sebastian.huber-L1vi/***@public.gmane.org
PGP : Public key available on request.

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