From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F38E25.4060205@domain.hid> Date: Mon, 13 Oct 2008 20:06:29 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <48F34E5A.60209@domain.hid> <48F3527E.6020908@domain.hid> <48F35470.70600@domain.hid> <48F35785.6090503@domain.hid> In-Reply-To: <48F35785.6090503@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [BUG?] mem leak on slab size-1024 with Xenomai processes Reply-To: Gilles Chanteperdrix List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core Jan Kiszka wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> Jan Kiszka wrote: >>>> Sigh, this is not my day: Can anyone confirm that we are leaking memory >>>> with current SVN head? I'm seeing a constant increase on slab >>>> "size-1024" on a x86_64 box when running arbitrary Xenomai apps in a loop. >>>> >>>> [ Besides that, I have an occasional deadlock in xnpipe_wakeup_proc due >>>> to an inconsistent xnpipe_sleepq - likely a different story... :-/ ] >>>> >>> Any luck with CONFIG_XENOMAI_OPT_DEBUG_QUEUES on? >> As usual no luck: the bug disappeared (likely some race). Will dig into >> that next after fixing this leak: >> >> xnshadow_sys_event() >> XNSHADOW_CLIENT_ATTACH -> xnarch_alloc_host_mem(xnsys_ppd) >> XNSHADOW_CLIENT_DETACH -> ??? > > That was the key, now fixed with #4218. Ok. I think this one is mine. Sorry. -- Gilles.