From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48E7AE50.8070602@domain.hid> Date: Sat, 04 Oct 2008 19:56:32 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <48E76494.9030901@domain.hid> <48E778B3.8040004@domain.hid> <48E77F57.9010604@domain.hid> <48E78101.6070101@domain.hid> <48E7A71A.3040304@domain.hid> In-Reply-To: <48E7A71A.3040304@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] gdb lockup on multi-threaded process exit 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: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Hi, >>>>> >>>>> I'm banging my head against this issue for several days now, first >>>>> trying to sort out an unrelated bug I also came across at this chance, >>>>> then trying to understand what happens, and finally getting mad about >>>>> why this may only happen with Xenomai: >>>> I have not tried to understand your problem (yet). But do you happen to >>>> work with the latest TASK_ATOMICSWITCH changes? If yes, could you try to >>>> revert them? >>> Yes, I'm on latest trunk. During my debug endeavour, I haven't seen this >>> task state being involved. Also, if I got this correctly, it only >>> concerns the secondary->primary migration, and that one appears to be >>> out of scope here. Nevertheless, it's easy to verify if you tell me >>> which revision(s) I should revert. >> Should be: >> 4bc557d998f7cfac0a069d0c47e28510ef270cb2 >> and: >> acaccc82ead113f33f8f717fdafea14dba8b885d >> > > OK, I simply went back to 2.0-09 (I think I was there originally when > the bug showed up), but the effect remains the same. Just checked in the mean-time, trunk does not use the new version of TASK_ATOMICSWITCH. So, it can not be the issue. -- Gilles.