Re: [Xenomai-help] real time task disapears... memory problem ?

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

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

desvages@domain.hid wrote:
>> desvages@domain.hid wrote:
>>>> What kind of statistics would you precisely need? And where would you
>>>> need it, means where is your scheduler located, what API does it use?
>>> I need execution time (and not response time). A patch for this has been
>>> create by a former student (now Doctor David Robert) working before me.
>> Hmm, the patch looks like it consequently reimplements existing runtime
>> statistics instead of reusing them as a foundation...
>>
>> Anyway, I think we could discuss some API extension of Xenomai (for
>> native, probably via rt_task_inquire). Likely we would keep this report
>> optional, ie. make it return -1 or so if CONFIG_XENO_OPT_STATS is off.
>> Tracking stats is not as costly as other instrumentations, but it's also
>> not free. If you are interested, let us know. It won't be a one-liner,
>> but it doesn't look like it has to be as invasive as your approach.
> 
> It can be interesting to have something like that. My tutor will probably
> explain better than me what could be the best. I let him open a new topic
> on this patch.
> 
>>> You can find it enclosed with this mail. Anyway the problem doesn't come
>>> from this patch, it appears also with vanilla xenomai.
>> OK.
>>
>>>> Primarily code. We need your code that demonstrates the weird
>>>> behaviour.
>>>> If you patched Xenomai in any way, that patch would be required as well
>>>> of course.
>>> I have reduced the size of the code to the thing that is not working.
>>> You
>>> can find it enclosed.
>>> The main program creates a task that calls the gsl_qp function (a
>>> quadratic solver).
>>> The problem appends during the call of ql0001_. If I remove this call,
>>> it
>>> works. I if keep it, the task disapears without any error (I only see
>>> that
>>> in /proc/xenomai/stat ).
>> This sounds like some fault is triggered and your program simply
>> terminates on report of the same ("Hey, if I add that printf, my program
>> stops. What's wrong with printf?" -- You can't imagine how often I
>> already heard this. ;) ).
>>
>>>> BTW, did you already try to attach gdb to your disappearing process?
>>>> Maybe it can catch what makes it terminate.
>>> I have tried without success, but I don really know how to use it in
>>> that
>>> way...
>> You should compile it with "-g", start it with "gdb <your program>" (or
>> the graphical front-end "ddd"), simply let it "run" and wait what gdb
>> reports. It should really say /something/.
> 
> Yes I only know how to use ddd in fact, and the -g flag is used at compile
> time. And with ddd, no bug is found... I don't catch anything. The problem
> only appears when I launch the program  in console mode.
> The thing I didn't really know how to use id the attach command of gdb,
> that I have read on the web it can catch errors on program launched from
> outside gdb. Am I wrong ?
> 
>> I can't help anyway, some files are missing, at least gsl/gsl_matrix.h.
>> If I shall have a look, I really need a smaller test-case, only
>> including Xenomai interaction.
>>
> 
> It's a mistake, I forgot to remove this unuseful include line. I have
> tried to reduce the program at the minimum (some heap data allocation with
> random values, and a call to the optimizer function that cause the
> termination of the task). Normally you can remove this include, and there
> will only stay xenomai calls...
> 
>>> My config: (I have install the last availlable xenomai since last mail)
>>> - Linux kernel : 2.6.20.3
>>> - xenomai : 2.3.1
>>> - Adeos : 1.7-03
>>> - Laptop compact Evo N600c Pentium 3M 1.2Ghz
>>>
>>>> .config, Xenomai version, and I-pipe version can be helpful too.
>>> .config is enclosed (DentiX231)
>>>
>>>
>>>> Jan
>>> Thanks for your help
>>>
>>> Arnaud DESVAGES
>>>
>> Jan
> 
> Hope these new information will help to solve it.
> 

From my kernel console after running your program for a few seconds:

Xenomai: watchdog triggered -- killing runaway thread 'MyAlarmServer'

Previously, "rt_alarm_wait" was printed on the console, thus gsl_qp()
likely entered some infinite loop. You have the watchdog enabled as
well, so you should see the same effect, right?

Jan


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