Re: [Xenomai] Possible Xenomai fuse filesystem/registry queue status files issue?

[Steve Freyder <steve@freyder.net>]

On 4/2/2018 10:20 AM, Philippe Gerum wrote:
> On 04/02/2018 04:54 PM, Steve Freyder wrote:
>> On 4/2/2018 8:41 AM, Philippe Gerum wrote:
>>> On 04/01/2018 07:28 PM, Steve Freyder wrote:
>>>> Greetings again.
>>>>
>>>> As I understand it, for each rt_queue there's supposed to be a
>>>> "status file" located in the fuse filesystem underneath the
>>>> "/run/xenomai/user/session/pid/alchemy/queues" directory, with
>>>> the file name being the queue name.  This used to contain very
>>>> useful info about queue status, message counts, etc.  I don't know
>>>> when it broke or whether it's something I'm doing wrong but I'm
>>>> now getting a "memory exhausted" message on the console when I
>>>> attempt to do a "cat" on the status file.
>>>>
>>>> Here's a small C program that just creates a queue, and then does
>>>> a pause to hold the accessor count non-zero.
>>>>
>>> <snip>
>>>
>>>> The resulting output (logged in via the system console):
>>>>
>>>> # sh qtest.sh
>>>> + sleep 1
>>>> + ./qc --mem-pool-size=64M --session=mysession foo
>>>> + find /run/xenomai
>>>> /run/xenomai
>>>> /run/xenomai/root
>>>> /run/xenomai/root/mysession
>>>> /run/xenomai/root/mysession/821
>>>> /run/xenomai/root/mysession/821/alchemy
>>>> /run/xenomai/root/mysession/821/alchemy/tasks
>>>> /run/xenomai/root/mysession/821/alchemy/tasks/task@1[821]
>>>> /run/xenomai/root/mysession/821/alchemy/queues
>>>> /run/xenomai/root/mysession/821/alchemy/queues/foo
>>>> /run/xenomai/root/mysession/system
>>>> /run/xenomai/root/mysession/system/threads
>>>> /run/xenomai/root/mysession/system/heaps
>>>> /run/xenomai/root/mysession/system/version
>>>> + qfile='/run/xenomai/*/*/*/alchemy/queues/foo'
>>>> + cat /run/xenomai/root/mysession/821/alchemy/queues/foo
>>>> memory exhausted
>>>>
>>>> At this point, it hangs, although SIGINT usually terminates it.
>>>>
>>>> I've seen some cases where SIGINT won't terminate it, and a reboot is
>>>> required to clean things up.  I see this message appears to be logged
>>>> in the obstack error handler.  I don't think I'm running out of memory,
>>>> which makes me think "heap corruption".  Not much of an analysis!  I did
>>>> try varying queue sizes and max message counts - no change.
>>>>
>>> I can't reproduce this. I would suspect a rampant memory corruption too,
>>> although running the test code over valgrind (mercury build) did not
>>> reveal any issue.
>>>
>>> - which Xenomai version are you using?
>>> - cobalt / mercury ?
>>> - do you enable the shared heap when configuring ? (--enable-pshared)
>>>
>> I'm using Cobalt.  uname -a reports:
>>
>> Linux sdftest 4.1.18_C01571-15S00-00.000.zimg+83fdace666 #2 SMP Fri Mar
>> 9 11:07:52 CST 2018 armv7l GNU/Linux
>>
>> Here is the config dump:
>>
>> CONFIG_XENO_PSHARED=1
> Any chance you could have some leftover files in /dev/shm from aborted
> runs, which would steal RAM?
>
I've been rebooting before each test run, but I'll keep that in mind for
future testing.

Sounds like I need to try rolling back to an older build, I have a 3.0.5
and a 3.0.3 build handy.