[Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

Hi,

originally, I was hunting some mutex issue (still on it, report will
follow soon). But due to a typo I revealed some nasty clean-up issue of
current trunk (2.1.x seems to contain the same code). Try to create two
tasks like this:

        rt_task_spawn(&task1, "task1", 0, 20, 0, task1_fnc, 0);
        rt_task_spawn(&task2, "task1", 0, 10, 0, task2_fnc, 0);
	[I think rt_task_create would "work" as well.]

The second call will fail due to duplicate names - and will trigger the
lock-up at this chance. It's actually a NULL pointer fault caused like this:

(gdb) bt
#0  schedule_linux_call (type=4, p=0x0, arg=9) at shadow.c:343
                                 ^^^^^
                                 oops!
#1  0xc013b184 in xnshadow_send_sig (thread=<value optimized out>,
    sig=9, specific=<value optimized out>) at shadow.c:1087
#2  0xc492d7d0 in rt_task_delete (task=0xc1120d20) at task.c:591
#3  0xc492d4f7 in rt_task_create (task=0xc1120d20, name=0xc1375f1c
    "task1", stksize=0, prio=10, mode=3145728) at task.c:287

Sorry, no patch yet, I have to move on to the mutex issue first.

BTW, this reminds me the ask for a merging plan of the kgdb support for
ipipe - this bug was tracked down via kgdb...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]