From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4579248A.8040201@domain.hid> Date: Fri, 08 Dec 2006 09:38:34 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 Subject: Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5) References: <457826BC.1080008@domain.hid> In-Reply-To: <457826BC.1080008@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Thomas Wiedemann , xenomai@xenomai.org Jan Kiszka wrote: > Thomas Wiedemann wrote: > >>Hi, >> >>there seems to be a bug in rt_task_create(). When no more memory is >>available, the module usage counter of xeno_native is decremented. I >>guess it is not incremented before, however, so the counter gets 0 and >>wraps then to a negative number. It is therefore not possible to remove >>the module. >> >>I appended a small program to demonstrate this. It simply eats up all >>memory from xenomai by registering as much mutexes as possible, >>and then tries to execute rt_task_create(), which fails. When started >>again, the bug occurs at rt_task_shadow(), as the mutexes have never >>been deleted. >>Compile with gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config >> --xeno-ldflags` -lrtdm -lnative -o rttest rttest.c >>then simply run it, and watch the output of lsmod before and after. >> >>Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded: >>xeno_native and xeno_nucleus. >> > > > Confirmed. Requires a closer look to find the leak path. Here is what happens: the task is created with the XNSHADOW bit, and destroyed before it was xnshadow_mapped, but the deletion hook calls xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap decrements the module count. -- Gilles Chanteperdrix