Re: [Xenomai] [Xenomai-git] Jan Kiszka : lib/cobalt: Rework minimum stack size enforcement

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2015-04-21 18:37, Jan Kiszka wrote:
> Possibly the crash was limited to the case where the application set a
> stack address and Xenomai messed up the size. I'm rechecking this right
> now, and if we are lucky, PTHREAD_STACK_MIN turns out to be fine for
> Xenomai as well.

Too bad, it wasn't that easy. Just try this, even without Xenomai:

#include <stdio.h>
#include <pthread.h>
#include <limits.h>

void *thread_func(void *arg)
{
	fprintf(stderr, "crash %s\n", "me");
	return NULL;
}

int main(int argc, char *argv[])
{
	pthread_t thread;
	pthread_attr_t attr;

	pthread_attr_init(&attr);
	pthread_attr_setstacksize(&attr, PTHREAD_STACK_MIN);

	pthread_create(&thread, &attr, thread_func, NULL);

	pthread_join(thread, NULL);

	return 0;
}

Crashes on my x86-64 boxes all the time. stdout/printf is fine. Some
internal glibc function requires a lot of stack space.

The problem is that we trigger the very same pattern with warning() in
Xenomai. When that is called by the thread trampoline, the user cannot
run threads with otherwise totally fine PTHREAD_STACK_MIN.

Now we can
- ask the user to specify for more stack (by contract)
- reject too small stacks (my patches)
- warn about too small stacks, but accept them (maybe a compromise)
- simply ignore this

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux