Has anyone experienced the XAML runtime freeze occasionally? The freeze happens at a variable interval after pressing a custom button type. There are four buttons on a view and the freeze can happen after pressing any of the four buttons, but it doesn’t always happen after a certain number of button presses. When the freeze occurs, the button image stays in the “pressed” state, and does not “unpress”. If I press a button on the display that controls some hardware element, like the display brightness or volume, the system does respond (volume tone is played, display gets dimmer) but the screen indicator that shows the current volume/brightness does not appear. Are there any known issues with custom buttons in XAML or known issues that can cause the runtime engine to freeze in the way I have described? I didn’t have much luck with a generic Google search other than some references to OpenGLES.
We don’t have a lot of experience with XAML, so I try to give you some generic hints to track down the problem.
We see two basic error sources:
- It could be related to the button event handler
- There could be issues in the XAML definitions themselves
If the event handler takes too long, or consumes 100% of the CPU time, the task to update the button graphics could get stuck.
In order to test this, you could try to remove the code from the button event handlers (or reduce it to a minimum). If the problem disappears, then the solution would probably be to move some code away from the event handlers into separate threads.
If you need more support, is it possible to provide a (stripped-down) version of your source code to allow us to reproduce the problem?
Can you also enable serial console you can set dbg.serial to 1 in the bootloader console or using config block editor.
Having a dump of the messages that may be generated on the console when the issue happens may help us understand it.
Are you using the S or DL version of imx6?
We are using the solo version Colibri iMX6. Unfortunately I don’t think I’ll get around to doing additional debug in the near future since the issue does not present itself during most modes of operation. I’ll post an update if I do get more time to look into this.
Thank you for the feedback. I’m sorry we don’t have a generic answer to your problem. We’re standing by for the update.
Are you using multiple threads?
We had problems when accessing UI elements from other threads, even when “AllowsMultipeThreadAccess” is set to true in XRWindowCreateParams
Thanks for the reply here. We do use multiple threads, but only one thread handles the UI elements. Our option “AllowsMultipleThreadAccess” is set to 0.
I’m another engineer working on this issue. I enabled symbols for the xamlruntime and was able to get the freeze to occur while debugging. This is what the call stack looks like when the exception occurs:
We don’t have access to the XAML source code, so we cannot dig into the call stack to find more details than what we see in the picture above.
The only surprising thing I see is that CheckAutomaticAutomationChanges() is called recursively many times. However, I don’t know XAML, so maybe this is even normal…
You could try to reduce the complexity of the XAML definition to check whether it helps to workaround your issue.