On 04/02/2018 06:11 PM, Steve Freyder wrote: > 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.
The standalone test should work with the shared heap disabled, could you check it against a build configure with --disable-pshared? Thanks, -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
