Hi all,
in case taskSpawn() fails due to lack of permissions in the current xenomai-forge checkout (tried with mercury), the following function ret = __bt(copperplate_create_thread(&cta, &task->thobj.tid)); returns ret != 0 and I get the following segmentation fault: http://pastebin.ca/2591742 holder->prev and holder->next seem to be nullptrs. I am not 100% sure how to fix this issue... I have a clone from the latest xenomai-forge.git/next. Also, I would like to ask about the xenomai-forge style of resources handles (e.g. tasks, queues, semaphores, etc.), which are actually pointers converted with the mainheap_ref and mainheap_deref macros. In the xenomai 2.6 implementation, handles were resolved via a registry, allowing the detection of handles on deleted objects. However, with the pointer-based approach in xenomai-forge, the result of a handle to a deleted object may either be gracefully detected (in case the memory is still readable and the magic does not match) or we will get a segmentation fault if the address has been freed. Obviously, since this happens in user mode, it will not have impact on kernel stability, and it indicates an improper use of a handle, but is still a different behaviour than xenomai 2.6.x. Is this desired or are there plans to solve this differently in the future (e.g. by using some sort of registry, etc.)? Thanks in advance for your answers, regards, Matthias _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
