Histogram demo crashes immediately on MacOS

[simplexidev]

Histogram demo crashes immediately on MacOS

[simplexidev]

Thank's for the confirmation! 😄

[simplexidev]

When I get done with work today, I'll be trying to just replace Set Identity with a constructor that adds the default values.

[simplexidev]

I'm hoping that replacing the native call with the actual logic, which just sets default matrix values (putting it here until I get off so I don't forget them) :

M11 = 1
M12 = 0
M21 = 0
M22 = 1,
M31 = 0,
M32 = 0

[simplexidev]

I created a branch for this, since I can't test the changes for macOS myself. I pushed some changes to LibUISharp.Drawing.Matrix.SetIdentity(), which doesn't call it's native method anymore. It will return a new Matrix with the default values listed in the uiDrawMatrixSetIdentity() method in libui's common/matrix.c.

[simplexidev]

Changing that method actually shows the histogram's points now on Windows. Weird, but there's more that needs done for the demo to function properly, since I'm getting an InvalidOperationException being thrown at various native methods when I continuously move the mouse over the histogram itself for ~-2-10s. Odd thing is that the native method that threw the exception changed depending on when I started to move the mouse, which would be from uiMain() or uiControlDestroy(c). It also shows the wrong color by default, and when chosen (some color component isn't set right, I think).

[scriptam]

Ditto. I've had to comment out MouseEvent on SurfaceHandler to get the demo running since moving the mouse over the surface alone was leading to a crash after a few seconds. It would be better to just listen in on MouseEventArgs when e.Down or similar interaction click to avoid queueing a redraw on every mouse movement event.
Similarly, if you hold down a spinbox for more than a couple of seconds, it will also cause a crash.
These issues are related: queueing too many redraw on UI in a very tight succession without a guard is likely for either the queue to overflow and/or the MacOS AppKit to crash.
To test: you can throttle successive requests with a yield or break them 200ms apart - you can see that crashes are avoided, since it gives the UI to clear off native draw tasks.
I looked at LibUISharp.Application.QueueMain which has a lock in there, but it won't hurt to check whether the corresponding C implementation is synchronous or not - best to check whether LibUI provides the safety when too many UI redraw calls are executed in tandem.

[scriptam]

Regarding the refactoring on branch for returning a Matrix with default values of (1, 0, 0, 1, 0, 0) - this again causes the same aforementioned crash on MacOS:

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

this time on uiDrawMatrixTranslate method:

public static void uiDrawMatrixTranslate(uiDrawMatrix matrix, double x, double y) => FunctionLoader.Load<uiDrawMatrixTranslate_t>("uiDrawMatrixTranslate")(matrix, x, y);```

[simplexidev]

I looked at LibUISharp.Application.QueueMain which has a lock in there, but it won't hurt to check whether the corresponding C implementation is synchronous or not - best to check whether LibUI provides the safety when too many UI redraw calls are executed in tandem.

Yeah, I need to start studying up on my C (which wouldn't hurt) and start scavenge all off the docs I can, mostly from libui-node. I'm not going to be doing much with this the next couple days, because work, but I will definitely be looking into this more after.

[simplexidev]

I'm going to (hopefully) finish updating the libui binaries to a more recent commit. This might fix the issue, although I sort of doubtful about it.

[simplexidev]

These issues are related: queueing too many redraw on UI in a very tight succession without a guard is likely for either the queue to overflow and/or the MacOS AppKit to crash.
To test: you can throttle successive requests with a yield or break them 200ms apart - you can see that crashes are avoided, since it gives the UI to clear off native draw tasks.

Where were you adding the 200ms breaks?

[scriptam]

Where were you adding the 200ms breaks?

LibUISharp.Drawing.Surface.QueueRedrawAll method. If this method was called in rapid succession (like the MouseEvent or holding down the SpinBox) it was leading to a crash, so tried throttling it before it calls Libui.uiAreaQueueRedrawAll(this); Used a queue inside the method and a task that flushed the queue in said intervals to probe where the issue lies.

[simplexidev]

I'm having a similar issue on Linux, but I haven't a clue why the window isn't showing up, since it's just giving me a bash segmentation fault. Applying the 200ms break made the the segmentation fault occur 20,000 lines later than before, so I'm assuming it's a related issue, just possibly on a different method. I'll have to see what's going on with this (Noting that this is occurs when built and ran with either the dotnet CLI, or MonoDevelop on Ubuntu 18.04 for reference).

EDIT: These errors are quite annoying, since there's no exception thrown, even when debugging.

[simplexidev]

My last commit may fix the Matrix issues for you on the macOS platform, but (again) this fixes the issue on Windows. I also have QueueRedrawAll() sleep for 200ms before calling the native method, and that seems to work. Thanks for that.

[scriptam]

Thanks Tom. The matrix issue is resolved on MacOS as well. Thanks

[scriptam]

The Histogram program no longer crashes on launch after @tom-corwin's latest commit