From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4399B973.8090009@domain.hid> Date: Fri, 09 Dec 2005 18:05:55 +0100 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete References: <43986AFA.6060908@domain.hid> <4399B6B8.8030209@domain.hid> <4399B81F.2030106@domain.hid> In-Reply-To: <4399B81F.2030106@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: xenomai-core Jan Kiszka wrote: > Philippe Gerum wrote: > >>Jan Kiszka wrote: >> >>>Hi all, >>> >>>during my ongoing search for the init/cleanup issue of shadow threads, I >>>stumbled over another problem: Deleting a userspace native thread that >>>is blocked in primary mode does not let the NPTL clean up all resources >>>allocated in userspace. If you plan to do some rt_task_create/delete in >>>a loop, you will soon run out of memory (and Mr. oom-killer will show >>>up...). >>> >>>I haven't found a solution for this beyond letting a rt-task always >>>terminate itself (or terminate the whole program after forced >>>deletions). If there is no solution, we should at least document this >>>fact somewhere. >>> >>>Again, it's not a common use case, but it's also not an expectable >>>behaviour of the native skin. >>> >> >>I see no possible workaround to allow a shadow thread deletion from >>kernel space while still leaving the opportunity for the NPTL thread to >>perform some user-space cleanups; recycling a previous Xenomai context >>to unwind a Linux context would lead to some terminally broken >>situation, so the nucleus must reap the terminated shadow at kernel >>level asap. However, the rt_task_delete() wrapper from the user-space >>support library might preferably pthread_kill() the thread, instead of >>asking the nucleus for that purpose. > > > Hmm, I think I've read something about signal delivery and handling in > threads which said that the delivery is per thread, but the handling > remains to affect the whole process. Thus, I'm afraid we may kill > ourselves here and not just the thread... > If the signal ends up being lethal, yes. All threads would be wiped out. I was thinking of catching a signal to perform a per-thread cleanup over the terminated context and pthread_exit later on. > Ok, Versuch macht klug (in English: just give it a try)! > > Jan > -- Philippe.