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? -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
