OpenMAX tear down

[rownyr]

I'm at code-debug-test stage of OMX development, and I'm not freeing any buffers yet. I'm just calling OMX_Deinit() at the end. Sometimes I break the program with Ctrl+C...

I've found that after number of iterations I get the OMX_ErrorInsufficientResources error. Shouldn't OpenMAX library free all the buffers/components when program using OMX is terminated? What about the situation when the program crashes? It seems that it will be necessary to reboot the OS to fix this, and that looks so wrong to me... every other linux API will not leak memory when its clients are terminated or crashed.

Edit: I forgot, but I'm actually freeing components with OMX_FreeHandle().

[linuxstb]

You're definitely not alone with this - I'm getting the same problems with my pidvbip app.

[jamesh]

The issue is that the memory is allocated on the GPU - not in Linux space. BUT that said, it should clean up after itself - if it isn't then that's likely a bug somewhere. Have you got simple example code that exhibits the problem?

[linuxstb]

The issue is that the memory is allocated on the GPU - not in Linux space. BUT that said, it should clean up after itself - if it isn't then that's likely a bug somewhere. Have you got simple example code that exhibits the problem?

I've been playing a little with the hello_pi samples to try and get simple examples of this.

Strangely, I can't get hello_video to leak GPU resources - either exit() calls into the code or using CTRL-C, "vcdbg reloc" shows everything is cleaned up.

However, if I try hello_videocube, and press CTRL+C whilst it's running, then I get resource leaks on the GPU.

[jamesh]

Thanks, that's useful. I'll ask Dom or someone who knows about this stuff to take a look.

[dom]

All GPU memory/resources should be released when the arm process exits.

I think the EGL error is this one:
https://github.com/raspberrypi/firmware/issues/185

No fix yet.

A leak in openmax was fixed about 2 months ago - is your firmware up to date?
https://github.com/raspberrypi/firmware/issues/172

[linuxstb]

Yes, I was running a recent (i.e. week or two old) firmware. I've just updated again to be sure (running "rpi-update" with no arguments) and my problems remain.

If it helps, here is an examnple of the output of "vcdbg reloc" after my app crashes.

Code: Select all

[ 555] 0xb73eae0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xb73f000, d1ruaL) 'video_decodeRIL:image pool'
[ 554] 0xba3cb60: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xba3d000, d1ruAL) 'video_decodeRIL:image pool'
[ 553] 0xbd3abe0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xbd3b000, d1ruaL) 'video_decodeRIL:image pool'
[ 552] 0xc038c60: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xc039000, d1ruaL) 'video_decodeRIL:image pool'
[ 551] 0xc336ce0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xc337000, d1ruAL) 'video_decodeRIL:image pool'
[ 550] 0xc634d60: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xc635000, d1ruAL) 'video_decodeRIL:image pool'
[ 549] 0xc932de0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0xc933000, d1ruAL) 'video_decodeRIL:image pool'

Digging into this, I think this may explain the issue I've reported in this thread - http://www.raspberrypi.org/phpBB3/viewt ... 70&t=48198 - where I can't shutdown the video_decode component. The above output is what I get in that situation.

From memory, I think I've also seen other leftovers on the GPU, if I can recreate, I'll post the details.

Thanks.

[dom]

From memory, I think I've also seen other leftovers on the GPU, if I can recreate, I'll post the details.

Ideally create a simple program (e.g. something based on hello_video code) that shows the problem.

[linuxstb]

From memory, I think I've also seen other leftovers on the GPU, if I can recreate, I'll post the details.

Ideally create a simple program (e.g. something based on hello_video code) that shows the problem.

After a bit more testing, all I seem to get (in addition to the EGL stuff) is the video_decodeRIL:image pool buffers.

I'll see what I can do about creating a test case, but as I said earlier in this thread, hello_video seems fine. Could the significant difference between my app and hello_video be the use of pthreads?

[dom]

I'll see what I can do about creating a test case, but as I said earlier in this thread, hello_video seems fine. Could the significant difference between my app and hello_video be the use of pthreads?

No. pthreads are used internally by openmax (and omxplayer/xbmc).

[rownyr]

All GPU memory/resources should be released when the arm process exits.

I think the EGL error is this one:
https://github.com/raspberrypi/firmware/issues/185

No fix yet.

A leak in openmax was fixed about 2 months ago - is your firmware up to date?
https://github.com/raspberrypi/firmware/issues/172

Yes, it's the latest firmware and raspbian. All updates installed by apt-get update + dist-upgrade and rpi-update.

This is my vcdbg reloc output after running my openmax program multiple times:

Code: Select all

Relocatable heap version 4 found at 0x10000000
total space allocated is 236M, with 236M relocatable, 0 legacy and 0 offline
0 legacy blocks of size 2359296

free list at 0x11a21640
next pointer 0x43040 out of bounds in free list at 0x1e97c960
1.4M free memory in 2 free block(s)
largest free block is 1.2M bytes

[   1] 0x10000000: used 4.0K (refcount 1 lock count 0, size        0, align 4096, data 0x10001000, d1rual) 'camera fast alloc arena'
[   2] 0x10001000: used  16K (refcount 1 lock count 0, size    16384, align   32, data 0x10001020, d0ruAl) 'audioplus_tmp_buf'
[   3] 0x10005020: used 4.0M (refcount 1 lock count 8, size  4177920, align 4096, data 0x10006000, d3rual) 'ARM FB'
[   4] 0x10402020: used  544 (refcount 1 lock count 0, size      512, align    4, data 0x10402040, d0rual) 'ILCS VC buffer pool'
[   5] 0x10402240: used  544 (refcount 1 lock count 0, size      512, align    4, data 0x10402260, d0rual) 'ILCS VC buffer pool'
[  18] 0x10402460: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x10402480, d1ruAl) 'RIL buffer'
[  13] 0x10416480: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104164a0, d1ruAl) 'RIL buffer'
0x1042a4a0: free 23M
[  17] 0x11b4b0c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x11b4b0e0, d1rual) 'RIL buffer'
[  22] 0x11e480e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x11e48100, d1rual) 'RIL buffer'
[  23] 0x12145100: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x12145120, d1ruAl) 'RIL buffer'
[  24] 0x12442120: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x12442140, d1ruAl) 'RIL buffer'
[  25] 0x1273f140: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1273f160, d1rual) 'RIL buffer'
[   7] 0x12a3c160: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x12a3c180, d1rual) 'RIL buffer'
[  26] 0x12d39180: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x12d391a0, d1rual) 'RIL buffer'
[  28] 0x130361a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x130361c0, d1ruAl) 'RIL buffer'
[  29] 0x133331c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x133331e0, d1rual) 'RIL buffer'
[  30] 0x136301e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x13630200, d1rual) 'RIL buffer'
[  31] 0x1392d200: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1392d220, d1ruAl) 'RIL buffer'
[  32] 0x13c2a220: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x13c2a240, d1rual) 'RIL buffer'
[  33] 0x13f27240: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x13f27260, d1rual) 'RIL buffer'
[  34] 0x14224260: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x14224280, d1ruAl) 'RIL buffer'
[  35] 0x14521280: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x145212a0, d1rual) 'RIL buffer'
[  36] 0x1481e2a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1481e2c0, d1ruAl) 'RIL buffer'
[  37] 0x14b1b2c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x14b1b2e0, d1rual) 'RIL buffer'
[  38] 0x14e182e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x14e18300, d1ruAl) 'RIL buffer'
[  39] 0x15115300: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x15115320, d1rual) 'RIL buffer'
[  40] 0x15412320: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x15412340, d1rual) 'RIL buffer'
[  41] 0x1570f340: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1570f360, d1ruAl) 'RIL buffer'
[  42] 0x15a0c360: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x15a0c380, d1ruAl) 'RIL buffer'
[  43] 0x15d09380: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x15d093a0, d1rual) 'RIL buffer'
[  44] 0x160063a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x160063c0, d1rual) 'RIL buffer'
[  45] 0x163033c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x163033e0, d1ruAl) 'RIL buffer'
[  46] 0x166003e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x16600400, d1ruAl) 'RIL buffer'
[  47] 0x168fd400: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x168fd420, d1rual) 'RIL buffer'
[  48] 0x16bfa420: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x16bfa440, d1rual) 'RIL buffer'
[  49] 0x16ef7440: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x16ef7460, d1rual) 'RIL buffer'
[  50] 0x171f4460: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x171f4480, d1ruAl) 'RIL buffer'
[  51] 0x174f1480: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x174f14a0, d1rual) 'RIL buffer'
[  52] 0x177ee4a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x177ee4c0, d1ruAl) 'RIL buffer'
[  53] 0x17aeb4c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x17aeb4e0, d1rual) 'RIL buffer'
[  54] 0x17de84e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x17de8500, d1rual) 'RIL buffer'
[  55] 0x180e5500: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x180e5520, d1ruAl) 'RIL buffer'
[  56] 0x183e2520: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x183e2540, d1ruAl) 'RIL buffer'
[  57] 0x186df540: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x186df560, d1rual) 'RIL buffer'
[  58] 0x189dc560: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x189dc580, d1rual) 'RIL buffer'
[  59] 0x18cd9580: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x18cd95a0, d1rual) 'RIL buffer'
[  60] 0x18fd65a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x18fd65c0, d1rual) 'RIL buffer'
[  61] 0x192d35c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x192d35e0, d1ruAl) 'RIL buffer'
[  62] 0x195d05e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x195d0600, d1rual) 'RIL buffer'
[  63] 0x198cd600: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x198cd620, d1rual) 'RIL buffer'
[  64] 0x19bca620: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x19bca640, d1rual) 'RIL buffer'
[  65] 0x19ec7640: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x19ec7660, d1rual) 'RIL buffer'
[  66] 0x1a1c4660: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1a1c4680, d1rual) 'RIL buffer'
[  67] 0x1a4c1680: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1a4c16a0, d1ruAl) 'RIL buffer'
[  68] 0x1a7be6a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1a7be6c0, d1ruAl) 'RIL buffer'
[  69] 0x1aabb6c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1aabb6e0, d1rual) 'RIL buffer'
[  70] 0x1adb86e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1adb8700, d1ruAl) 'RIL buffer'
[  71] 0x1b0b5700: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1b0b5720, d1rual) 'RIL buffer'
[  72] 0x1b3b2720: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1b3b2740, d1ruAl) 'RIL buffer'
[  73] 0x1b6af740: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1b6af760, d1rual) 'RIL buffer'
[  74] 0x1b9ac760: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1b9ac780, d1ruAl) 'RIL buffer'
[  75] 0x1bca9780: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1bca97a0, d1rual) 'RIL buffer'
[  76] 0x1bfa67a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1bfa67c0, d1rual) 'RIL buffer'
[  77] 0x1c2a37c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1c2a37e0, d1ruAl) 'RIL buffer'
[  78] 0x1c5a07e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1c5a0800, d1rual) 'RIL buffer'
[  79] 0x1c89d800: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1c89d820, d1ruAl) 'RIL buffer'
[  80] 0x1cb9a820: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1cb9a840, d1ruAl) 'RIL buffer'
[  81] 0x1ce97840: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1ce97860, d1rual) 'RIL buffer'
[  82] 0x1d194860: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1d194880, d1ruAl) 'RIL buffer'
[  83] 0x1d491880: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1d4918a0, d1rual) 'RIL buffer'
[  84] 0x1d78e8a0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1d78e8c0, d1rual) 'RIL buffer'
[  85] 0x1da8b8c0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1da8b8e0, d1rual) 'RIL buffer'
[  86] 0x1dd888e0: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1dd88900, d1ruAl) 'RIL buffer'
[  87] 0x1e085900: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1e085920, d1rual) 'RIL buffer'
[  88] 0x1e382920: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1e382940, d1ruAl) 'RIL buffer'
[  89] 0x1e67f940: used 3.0M (refcount 1 lock count 0, size  3133440, align   32, data 0x1e67f960, d1rual) 'RIL buffer'
[  15] 0x1e97c960: used 268K (refcount 1 lock count 1, size   274496, align   32, data 0x1e97c980, d0Rual) 'Vdec3 Msgbuf'
0x1e9bf9c0: free 2.3M
small allocs not requested

I couldn't narrow it to a simple test case so I gave up. I can send compiled program if that can help.

[rownyr]

Another reloc log I've got, this time "corrupted":

Code: Select all

Relocatable heap version 4 found at 0x10000000
total space allocated is 236M, with 236M relocatable, 0 legacy and 0 offline
0 legacy blocks of size 2359296

free list at 0x11b910c0
next pointer 0x200 out of bounds in free list at 0x11b910c0
545 free memory in 1 free block(s)
largest free block is 545 bytes

[   1] 0x10000000: used 4.0K (refcount 1 lock count 0, size        0, align 4096, data 0x10001000, d1rual) 'camera fast alloc arena'
[   2] 0x10001000: used  16K (refcount 1 lock count 0, size    16384, align   32, data 0x10001020, d0ruAl) 'audioplus_tmp_buf'
[   3] 0x10005020: used 4.0M (refcount 1 lock count 8, size  4177920, align 4096, data 0x10006000, d3rual) 'ARM FB'
[   4] 0x10402020: used  544 (refcount 1 lock count 1, size      512, align    4, data 0x10402040, d0rual) 'ILCS VC buffer pool'
[   5] 0x10402240: used  544 (refcount 1 lock count 0, size      512, align    4, data 0x10402260, d0rual) 'ILCS VC buffer pool'
[  30] 0x10402460: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x10402480, d1rual) 'RIL buffer'
[  23] 0x10416480: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104164a0, d1rual) 'RIL buffer'
[  10] 0x1042a4a0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1042a4c0, d1rual) 'RIL buffer'
[  18] 0x1043e4c0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1043e4e0, d1rual) 'RIL buffer'
[  32] 0x104524e0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x10452500, d1rual) 'RIL buffer'
[  20] 0x10466500: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x10466520, d1rual) 'RIL buffer'
[  13] 0x1047a520: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1047a540, d1rual) 'RIL buffer'
[   6] 0x1048e540: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1048e560, d1rual) 'RIL buffer'
[  21] 0x104a2560: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104a2580, d1rual) 'RIL buffer'
[  19] 0x104b6580: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104b65a0, d1rual) 'RIL buffer'
[   8] 0x104ca5a0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104ca5c0, d1rual) 'RIL buffer'
[  22] 0x104de5c0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104de5e0, d1rual) 'RIL buffer'
[  14] 0x104f25e0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x104f2600, d1rual) 'RIL buffer'
[  26] 0x10506600: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x10506620, d1rual) 'RIL buffer'
[  25] 0x1051a620: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1051a640, d1rual) 'RIL buffer'
[  38] 0x1052e640: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1052e660, d1rual) 'RIL buffer'
[  28] 0x10542660: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x10542680, d1rual) 'RIL buffer'
[  27] 0x10556680: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x105566a0, d1rual) 'RIL buffer'
[  34] 0x1056a6a0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1056a6c0, d1rual) 'RIL buffer'
[  35] 0x1057e6c0: used  80K (refcount 1 lock count 0, size    81920, align   32, data 0x1057e6e0, d1rual) 'RIL buffer'
[   9] 0x105926e0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x10593000, d1rual) 'video_decodeRIL:image pool'
[  11] 0x10890760: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x10891000, d1ruAl) 'video_decodeRIL:image pool'
[  12] 0x10b8e7e0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x10b8f000, d1ruAl) 'video_decodeRIL:image pool'
[   7] 0x10e8c860: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x10e8d000, d1rual) 'video_decodeRIL:image pool'
[  17] 0x1118a8e0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x1118b000, d1ruAl) 'video_decodeRIL:image pool'
[  16] 0x11488960: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x11489000, d1rual) 'video_decodeRIL:image pool'
[  24] 0x117869e0: used 3.0M (refcount 1 lock count 0, size  3133568, align 4096, data 0x11787000, d1rual) 'video_decodeRIL:image pool'
[  15] 0x11a84a60: used 2.2K (refcount 1 lock count 0, size     2240, align   32, data 0x11a84a80, d0Rual) 'H264 SPS'
[  37] 0x11a85340: used  17K (refcount 1 lock count 0, size    17424, align   32, data 0x11a85360, d0Rual) 'H264 PPS'
[  29] 0x11a89780: used 1.0M (refcount 1 lock count 1, size  1048576, align  256, data 0x11a89800, d3Rual) 'Vdec3 CDB'
[  40] 0x11b89880: used  15K (refcount 1 lock count 0, size    15360, align   32, data 0x11b898a0, d1rual) 'RIL buffer'
[  41] 0x11b8d4a0: used  15K (refcount 1 lock count 0, size    15360, align   32, data 0x11b8d4c0, d1rual) 'RIL buffer'
[  43] 0x11b910c0: used  544 (refcount 1 lock count 0, size      512, align    4, data 0x11b910e0, d0rual) 'ILCS VC buffer pool'
0x11b912e0: corrupt entry (space 0xb8bbb999)
could not resync
heap corruption detected
small allocs not requested

[andoma]

For the record, Showtime (http://github.com/andoma/showtime) suffers from the same problem.

Trying to investigate...

[andoma]

Seems the bug was related to not waiting for ports to be disabled before tearing down tunnel between components.

I also notice that some components (in particular the clock component I think) never trips a confirmation callback that it has completed the disable its output ports. Is this some kind of expected behavour or is my code screwed up?