From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <530C8C54.7090706@marel.com> Date: Tue, 25 Feb 2014 12:28:04 +0000 From: Marcel van Mierlo MIME-Version: 1.0 References: <52FBA4D5.3010606@marel.com> <52FCA810.2080604@marel.com> <530C8967.2050900@marel.com> In-Reply-To: <530C8967.2050900@marel.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] resource leak and kernel panic with pSOS q_vcreate on arm (BeagleBone Black) List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org On 25/02/14 12:15, Marcel van Mierlo wrote: > Hi, > > I posted this information a few weeks back but got no response...does > anyone have insight on this...I've been digging into the queue > management code in Xenomai but I'm not getting very far...any help on > this would be appreciated as I am not sure what to try next. > > This behaviour has been observed on BeagleBoard Black Linux arm > 3.8.13-bone26.1, Xenomai 2.6.3 > > basically the resources created by pSOS q_vcreate do not appear to be > released when the application exits. q_create appears to be fine. When > the application starts up again after exit (without calling > q_vdelete), calling q_vcreate on the named queue returns (-17 File > Exists). If I instead use q_vident to get a handle on the queue, the > API appears to return with a valid handle, but when the program exits > the second time Xenomai appears to sit in a resource-release loop and > I end up with a kernel panic. This is a non-trivial application with > about 30 running tasks and lots of fixed size queues using CAN. The > system is stable except for v-queues so there certainly seems to be > something amiss here. I have included a trivial test case which > reproduces the problem. > > [ 144.346739] Kernel panic - not syncing: softlockup: hung tasks > [ 144.352845] [] (unwind_backtrace+0x0/0xe0) from > [] (panic+0x84/0x1e0) > [ 144.361426] [] (panic+0x84/0x1e0) from [] > (watchdog_timer_fn+0x120/0x164) > [ 144.370338] [] (watchdog_timer_fn+0x120/0x164) from > [] (__run_hrtimer+0xec/0x1e4) > [ 144.379976] [] (__run_hrtimer+0xec/0x1e4) from > [] (hrtimer_interrupt+0x108/0x25c) > [ 144.389614] [] (hrtimer_interrupt+0x108/0x25c) from > [] (omap2_gp_timer_interrupt+0x44/0x54) > [ 144.400162] [] (omap2_gp_timer_interrupt+0x44/0x54) from > [] (handle_irq_event_percpu+0x60/0x214) > [ 144.411156] [] (handle_irq_event_percpu+0x60/0x214) from > [] (handle_irq_event+0x3c/0x5c) > [ 144.421430] [] (handle_irq_event+0x3c/0x5c) from > [] (handle_level_irq+0x98/0xd0) > [ 144.430974] [] (handle_level_irq+0x98/0xd0) from > [] (generic_handle_irq+0x20/0x30) > [ 144.440700] [] (generic_handle_irq+0x20/0x30) from > [] (handle_IRQ+0x64/0x8c) > [ 144.449886] [] (handle_IRQ+0x64/0x8c) from [] > (__ipipe_do_sync_stage+0x1f4/0x220) > [ 144.459526] [] (__ipipe_do_sync_stage+0x1f4/0x220) from > [] (ipipe_unstall_root+0x30/0x3c) > [ 144.469887] [] (ipipe_unstall_root+0x30/0x3c) from > [] (vprintk_emit+0x444/0x4bc) > [ 144.479428] [] (vprintk_emit+0x444/0x4bc) from > [] (vprintk+0x1c/0x20) > [ 144.487974] [] (vprintk+0x1c/0x20) from [] > (printk+0xa4/0x144) > [ 144.495891] [] (printk+0xa4/0x144) from [] > (psos_shadow_eventcb+0x7f8/0x16b8) > [ 144.505169] [] (psos_shadow_eventcb+0x7f8/0x16b8) from > [] (detach_ppd+0x28/0x44) > [ 144.514718] [] (detach_ppd+0x28/0x44) from [] > (taskexit_event+0x5ec/0x884) > [ 144.523724] [] (taskexit_event+0x5ec/0x884) from > [] (ipipe_kevent_hook+0x24/0x2c) > [ 144.533367] [] (ipipe_kevent_hook+0x24/0x2c) from > [] (__ipipe_notify_kevent+0x3c/0x64) > [ 144.543457] [] (__ipipe_notify_kevent+0x3c/0x64) from > [] (do_exit+0x348/0x88c) > [ 144.552819] [] (do_exit+0x348/0x88c) from [] > (do_group_exit+0x84/0xc0) > [ 144.561465] [] (do_group_exit+0x84/0xc0) from > [] (get_signal_to_deliver+0x49c/0x508) > [ 144.571375] [] (get_signal_to_deliver+0x49c/0x508) from > [] (do_signal+0x90/0x478) > [ 144.581018] [] (do_signal+0x90/0x478) from [] > (do_work_pending+0x5c/0xa4) > [ 144.589966] [] (do_work_pending+0x5c/0xa4) from > [] (work_pending+0xc/0x20) > [ 144.598961] drm_kms_helper: panic occurred, switching back to text > console > > In summary: > > 1. "USED main heap" under /proc/xenomai/heap does not return to > previous level after terminating an application which uses q_vcreate - > it is increased. > 2. After (1) has occurred, calling q_vcreate in a separate > invocation of the application returns -17 (File Exists) - suggesting > the queue is still in existence. This happens with plenty of "main > heap" left. I would expect all resources associated with the queue to > be released on termination. "USED main heap" is increased after > termination for this scenario as well, which certainly seems wrong. > > > [ 677.528359] Xenomai: pSOS: cleaning up q "q002" (ret=58). > whenever exiting without calling q_vdelete after q_vcreate. > > When using q_create, on exit I get: > [ 445.419293] Xenomai: pSOS: cleaning up q "q001" (ret=0). > when I do not call q_delete. > > I've included a simple test case which demonstrates the problem. > > Any assistance with this would be appreciated. > > > Marcel. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: qvcreatetest.tar.gz > Type: application/x-gzip > Size: 625 bytes > Desc: not available > URL: > > _______________________________________________ > Xenomai mailing list > Xenomai@xenomai.org > http://www.xenomai.org/mailman/listinfo/xenomai > OK, digging a little further...If I check for the v-queues existence at start up (before attempting to create it) using q_vident and then *do not* call q_vdelete on it I seem to be able to avoid the kernel panic and resource leak...not sure whether the v-queue is actually usable the second time around yet....but it seems that it may get created ok, just messed up at point of deletion. Marcel.