Closed nixtar closed 1 year ago
Unsure what changed for this to happen, but I've now reproduced this issue on 11 Preview 3 with only the TextBlock and NumericUpDown control. So maybe it's a red herring that it's caused by certain controls.
Seems like the other controls such as Slider and TimePicker appear to make it happen more consistatntly. It also seems to occur a lot faster when utilising the touch screen on the Slider or TimePicker.
If I run the app with the following xaml and just leave it idle it takes a minute or so to die. But it I instantly start playing around with the time picker with the touch screen it locks up in 3-5 seconds.
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center" Margin="30" Spacing="30">
<ProgressBar IsIndeterminate="True" />
<TimePicker />
</StackPanel>
Again, I'm unable to fault 0.10.18.
When I get some time to play with this again, I'll try the latest CI build.
Do you have a stack trace from the application?
Do you have a stack trace from the application?
No, it doesn't crash in a nice way, it just stops rendering until you kill it externally.
I managed to get a debugger attached over ssh and the dotnet side of the app appears to still be ticking along.
I can pause the app and see the following in the stack:
System.Private.CoreLib.dll!System.Threading.WaitHandle.WaitMultiple(System.ReadOnlySpan<System.Threading.WaitHandle> waitHandles, bool waitAll, int millisecondsTimeout)
System.Private.CoreLib.dll!System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[] waitHandles, bool waitAll, int millisecondsTimeout)
Avalonia.Controls!Avalonia.Controls.Platform.InternalPlatformThreadingInterface.RunLoop(System.Threading.CancellationToken cancellationToken)
Avalonia.Base!Avalonia.Threading.Dispatcher.MainLoop(System.Threading.CancellationToken cancellationToken)
Avalonia.Controls!Avalonia.Controls.DesktopApplicationExtensions.Run(Avalonia.Application app, System.Threading.CancellationToken token)
Avalonia.LinuxFramebuffer!LinuxFramebufferPlatformExtensions.StartLinuxDirect<Avalonia.AppBuilder>(Avalonia.AppBuilder builder, string[] args, Avalonia.LinuxFramebuffer.Output.IOutputBackend outputBackend, Avalonia.LinuxFramebuffer.Input.IInputBackend inputBackend)
Avalonia.LinuxFramebuffer!LinuxFramebufferPlatformExtensions.StartLinuxDrm<Avalonia.AppBuilder>(Avalonia.AppBuilder builder, string[] args, string card, double scaling, Avalonia.LinuxFramebuffer.Input.IInputBackend inputBackend)
AvaloniaTest!AvaloniaTest.Program.Main(string[] args) Line 20
Please, show dmesg
output
Please, show
dmesg
output
Sorry for the delay.
does setting UseCompositor to false prevent the fault?
does setting UseCompositor to false prevent the fault?
Unless I'm missing something, LinuxFramebufferPlatformOptions
has no UseCompositor
property?
Is there another Platform Options class that works with StartLinuxDrm
?
FYI, I've reproduced this issue on dotnet 7.0.100 and Avalonia 11.0.0-preview4.
Please feel free to let me know if there is anything you would like me to try.
does setting UseCompositor to false prevent the fault?
Unless I'm missing something,
LinuxFramebufferPlatformOptions
has noUseCompositor
property? Is there another Platform Options class that works withStartLinuxDrm
?
Sorry, I just assumed framebuffer had the same options. I don't know if there is another way to turn off Composition.
I can confirm that this issue happens not only on Raspberry PI but other (Embedded) Linux Systems as well. I am using Avalonia 11.0.0-preview4 (including Avalonia.LinuxFramebuffer 11.0.0-preview4) on a STM32MP1 demo-board (ARM Cortex-A9). As @nixtar, I am also using the minimal example from https://docs.avaloniaui.net/guides/deep-dives/running-on-raspbian-lite-via-drm. However, for me it does not seem to matter if I remove the Slider control or not, even with only the TextBlock, the application immediately hangs without showing anything on the screen. The same application works fine on this system with Avalonia 0.10.18.
Dmesg shows:
[ 746.730063] Alignment trap: not handling instruction ed910b00 at [<af4651b0>]
[ 746.736071] 8<--- cut here ---
[ 746.738948] Unhandled fault: alignment exception (0x001) at 0x004f54fa
[ 746.745437] pgd = 6d956803
[ 746.748235] [004f54fa] *pgd=c4102835, *pte=d15e175f, *ppte=d15e1c7f
Certain controls appear to cause Avalonia to hang when running on a Raspberry Pi with 11 Preview 1,2 and 3. When you kill the app in the terminal you can see a message
Unhandled fault: alignment exception (0x001) at {memory address}
.My device is a RasPi Zero 2 connected to a Pimoroni HyperPixel 2.1 Round display. Its running
Raspbian GNU/Linux 10 (buster) Lite
with the GL driver set toG2 GL (Fake KMS)
. I've tried Full KMS however the HyperPixel screen does not show any output when set to Full.Dotnet version: 6.0.402
I used https://docs.avaloniaui.net/guides/deep-dives/running-on-raspbian-lite-via-drm to create the project as described in the guide. With Avalonia 0.10.18 I can run the app without issues on the device. With Avalonia 11 Preview 3 the app runs for about 4 seconds then hangs. If I close the app via SSH I see the text on the screen:
Unhandled fault: alignment exception (0x001) at {memory address}
Note that after updating to Avalonia 11,builder.StartLinuxDrm(args)
becomes ambiguous and I resolved this by changing it tobuilder.StartLinuxDrm(args, scaling: 1)
If I remove the Slider control from the MainView.axaml then the app runs without hanging. I added an Indeterminate ProgressBar so I can see if the app is running or not and with just the TextBlock and ProgressBar it runs fine. NumericUpDown also seems to work fine.
However, TimePicker was another control that caused it to hang.
Works:
Hangs:
Most of my testing has been done on 11 Preview 3 however I did try with the Slider control on Preview 1 ,2 and 3. 0.10.18 appears to be fine with the controls I have tested so far. I've also tested dotnet 7 RC2 quickly and it had the same issue.
I'm not a very experienced developer with *nix OS's or these kinds of IoT devices so some guidance on how best to debug this would be appreciated.
Screenshot of the physical console after the app has hung a few times: