Raspberry Pi Application Crashed - GUI access?

Eugene_Dakin · June 9, 2025, 3:05am

Hello,

I created a Menu using native Raspberry Pi OS declares and the program crashed. There are two sets of menu items (File->Quit), and (Edit->Copy). When using DebugLog, there is no issue and no crashing. In the Quit command, I added the command Quit, and in the copy menu item I added both a debuglog and TextArea1.text = “some string”. Both worked when only DebugLog is used, and both crashed when either closing or accessing the GUI.

Is there a workaround that I can use to make this work? My wild guess would be to create preemptive threads, have Xojo run on one OS thread while running other commands in a different thread, but I am just taking wild guesses.

What could i do to update the GUI without Xojo’s GUI violation. Is there a way to programmatically turn-off the issue with Xojo and accessing the GUI? I can create a new OS window from scratch and access the new OS window without issues.

Attached is an example program with Xojo 2025 r1.1, on tested on Raspberry Pi 4.

Thanks for your thoughts.

Example6-05c.zip (19.6 KB)

Edit: I am building a Raspberry Pi Functionality Suite for declares, and am adding declares to the Github located at: GitHub - eugenedakin/PiFS: Raspberry Pi Functionality Suite - Xojo

Greg_O · June 9, 2025, 10:49am

I think you’re thinking of a ThreadAccessingUIException. This doesn’t appear to be that.

Christian_Schmitz · June 9, 2025, 10:50am

Can you run from Terminal, so an error message printed would show up there?

You may also just run it from Terminal via gdb and then when it crashes, you can use commands like “bt” to print backtrace and see which function crashed.

Eugene_Dakin · June 9, 2025, 2:23pm

Thanks for the suggestion to use bt @Christian_Schmitz.

When running the application crashed in Xojo debug within the IDE, the screen grab above show the same for both selecting copy and for exit.

When running the application in a terminal, only the Copy menuitem shows a segmentation fault and the Quit menuitem does not show a segmentation fault.

When getting the bt stacktrace, here are the results.

(gdb) run
Starting program: /home/DakServer/Desktop/New/Declare-RPi/Chapter06/Builds - Example6-05c/Linux ARM64/MyApplication/MyApplication 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ff269be00 (LWP 5624)]
[New Thread 0x7ff1e8be00 (LWP 5625)]
[New Thread 0x7ff166ae00 (LWP 5626)]
[New Thread 0x7ff0e2ee00 (LWP 5627)]
[Detaching after vfork from child process 5628]
[Detaching after vfork from child process 5629]
[Detaching after vfork from child process 5630]
[Detaching after vfork from child process 5633]
[Detaching after vfork from child process 5634]
[Detaching after vfork from child process 5635]
[Detaching after vfork from child process 5636]
[Detaching after vfork from child process 5637]
[Detaching after vfork from child process 5652]
[New Thread 0x7febfdee00 (LWP 5667)]
[Thread 0x7febfdee00 (LWP 5667) exited]
[New Thread 0x7febfdee00 (LWP 5668)]
[New Thread 0x7fe90ade00 (LWP 5669)]
[Thread 0x7febfdee00 (LWP 5668) exited]
[Thread 0x7fe90ade00 (LWP 5669) exited]
Copy MenuItem Selected

Thread 1 "MyApplication" received signal SIGSEGV, Segmentation fault.
0x0000007ff4c1c220 in ?? () from /lib/aarch64-linux-gnu/libgtk-3.so.0
(gdb) bt
#0  0x0000007ff4c1c220 in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#1  0x0000007ff4a92f5c in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#2  0x0000007ff4a72c18 in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#3  0x0000007ff4a72efc in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#4  0x0000007ff4a63688 in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#5  0x0000000000642548 in Window1.Window1.OnCopyActivated%%o<Window1.Window1>pp
    ()
#6  0x0000007ff41871f8 in g_closure_invoke ()
    at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#7  0x0000007ff419b5ac in  () at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#8  0x0000007ff41a18dc in g_signal_emit_valist ()
    at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#9  0x0000007ff41a1af0 in g_signal_emit ()
    at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#10 0x0000007ff4cd4c80 in gtk_widget_activate ()
--Type <RET> for more, q to quit, c to continue without paging--c
    at /lib/aarch64-linux-gnu/libgtk-3.so.0
#11 0x0000007ff4b6ced8 in gtk_menu_shell_activate_item () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#12 0x0000007ff4b6d28c in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#13 0x0000007ff49b2ac4 in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#14 0x0000007ff418575c in  () at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#15 0x0000007ff4187430 in  () at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#16 0x0000007ff41a0e88 in g_signal_emit_valist () at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#17 0x0000007ff41a1af0 in g_signal_emit () at /lib/aarch64-linux-gnu/libgobject-2.0.so.0
#18 0x0000007ff4cd14b8 in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#19 0x0000007ff4b52778 in  () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#20 0x0000007ff4b5454c in gtk_main_do_event () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#21 0x0000007ff482f218 in  () at /lib/aarch64-linux-gnu/libgdk-3.so.0
#22 0x0000007ff4869bdc in  () at /lib/aarch64-linux-gnu/libgdk-3.so.0
#23 0x0000007ff406766c in g_main_context_dispatch () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#24 0x0000007ff4067900 in  () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#25 0x0000007ff40679a4 in g_main_context_iteration () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#26 0x0000007ff4b536b4 in gtk_main_iteration_do () at /lib/aarch64-linux-gnu/libgtk-3.so.0
#27 0x0000007ff79a37ac in  ()
    at /home/DakServer/Desktop/New/Declare-RPi/Chapter06/Builds - Example6-05c/Linux ARM64/MyApplication/MyApplication Libs/XojoGUIFrameworkARM64.so
#28 0x0000000000582ed8 in DesktopApplication._CallFunctionWithExceptionHandling%%o<DesktopApplication>p ()
#29 0x0000007ff79a3608 in  ()
    at /home/DakServer/Desktop/New/Declare-RPi/Chapter06/Builds - Example6-05c/Linux ARM64/MyApplication/MyApplication Libs/XojoGUIFrameworkARM64.so
#30 0x0000007ff79a38a8 in  ()
    at /home/DakServer/Desktop/New/Declare-RPi/Chapter06/Builds - Example6-05c/Linux ARM64/MyApplication/MyApplication Libs/XojoGUIFrameworkARM64.so
#31 0x0000007ff79a070c in RuntimeRun ()
    at /home/DakServer/Desktop/New/Declare-RPi/Chapter06/Builds - Example6-05c/Linux ARM64/MyApplication/MyApplication Libs/XojoGUIFrameworkARM64.so
#32 0x00000000005bcac0 in REALbasic._RuntimeRun ()
#33 0x0000000000644b98 in _Main ()
#34 0x00000000006442a8 in main ()

I am not sure what to make of this information. Do you have any helpful thoughts?

Thanks.

Eugene_Dakin · June 9, 2025, 3:24pm

Hi Greg,

Just for the fun-of-it, I presumed a ThreadAccessingUIException and was able to get with working with another declare called g_idle_add. What this declare does it that a callback on GTK’s main loop is scheduled, and invokes a shared method with a made-up-name called XojoIdleHandler.

Here are the steps to implement g_idle_add:

in the OnCopyActivated method remove the line of code with TextArea1.Text = “Copy MenuItem Selected”
Create a shared method called XojoIdleHandler with the following code:

Public Shared Function XojoIdleHandler(pUserData as Ptr) As Integer
  Window1.SafeCopy
  Return 0
End Function

Create a regular method in Window1 called SafeCopy and paste the GUI accessing code.

Public Sub SafeCopy()
  TextArea1.Text = "Copy MenuItem Selected"
End Sub

Attached is the running code with Xojo 2025 r1.1 for the Raspberry Pi:
Example6-05d.zip (19.8 KB)

I’ll update the github code (GitHub - eugenedakin/PiFS: Raspberry Pi Functionality Suite - Xojo) tomorrow to include the g_idle_add declare for this workaround.

Although this works, is there an easier, more Xojo-native way of doing this? Or did I just happen to be lucky with the GUI access issue?

Greg_O · June 9, 2025, 4:47pm

It sounds like the menu handlers you made may natively not happen on the main thread and that your workaround is to have them do that. That’s not uncommon, even in obj-c.