Hang on open restore path

[basxto]

Clicking on Open Restore Path results in a frozen gbm for me.

Save Path: ${XDG_DATA_HOME:-~/.local/share}/Victor Vran/Victor Vran/

~/.local/share/Victor Vran/Victor Vran/ result in a freeze as well. I can’t use /home/dabascht/.local/share/Victor Vran/Victor Vran/ since that gets replaced automatically I linked /home2 to /home and /home2/dabascht/.local/share/Victor Vran/Victor Vran/ also freezes.

I’m not really sure what’s going wrong or whether this does not have anything to do with gbm at all. There are no errors or exceptions on the command line.

[MikeMaximus]

I'm unable to replicate the problem on Lubuntu 16.04 with latest stable Mono, which is all I have access to right now.

It's possible the method I use is broken with certain Window and/or File Managers.

If the restore path exists, GBM attempts to spawn a process to open a folder path. .NET/Mono is supposed to handle the request using the OS' default File Manager.

[basxto]

“Open Backup File” also does freezes. (opened with default archive program before) It seems I have to figure out how mono tries to open files with default application and why that fails.

xdg-open "/home/dabascht/.local/share/Victor Vran/Victor Vran/" works and I would expect that mono uses something liket hat.

Edit: How do you open files?

My small test worked like expected, it behaved like xdg-open.

Imports System
Imports System.Diagnostics

Module Module1
'This program will display Hello World 
   Sub Main()
      Process.Start("/home/dabascht/.local/share/Victor Vran/Victor Vran/")
      Process.Start("/home/dabascht/game_backup_monitor/savegames/The Stanley Parable/The Stanley Parable.7z")
      Console.WriteLine("Hello World")
      Console.ReadKey()
   End Sub
End Module

[MikeMaximus]

The same method basically, except I'm setting some other attributes for the process via the ProcessStartInfo object.

This is some code from opening a backup file.

oProcessStartInfo = New ProcessStartInfo
oProcessStartInfo.FileName = sFileName
oProcessStartInfo.UseShellExecute = True
oProcessStartInfo.Verb = "open"
Process.Start(oProcessStartInfo)

It's been quite a while since I wrote the code for that, so I don't remember why exactly I needed UseShellExecute enabled or the Verb set. You can try a combination of those to see if they cause a freeze in your test app.

[basxto]

With all those options it still works. Maybe my vbnc generates a different executable or the freeze happens before that.

Windows Shell is the graphical user interface of Windows. It’s possible that my test code did not work on Windows.

Edit: I used Open Restore Path with an invalid path and got to the error dialog. So it must be that block https://github.com/MikeMaximus/gbm/blob/030d8fca30f32aa314bcea30125b87dbcc87bc3a/GBM/Forms/frmGameManager.vb#L643-L651 But I have no clue why this fails and I also don’t know when I tried to use that button the last time.

Edit2: I’m using mono 5.16.0.220 and mono-basic 4.8 here. mono 5.18 isn’t in arch stable yet.

[MikeMaximus]

I'm at a loss as well, that code hasn't changed for a very long time. The fact your test app works with the same code makes it even more confusing.

Maybe it is an issue limited to 5.16, I confirmed that I do have 5.18 installed on my Lubuntu.

I'm going to take a browse through the Mono issues and see if anything similar is reported.

[basxto]

Ehrr I run my temporary GBM setup for the Windows game list with XDG_DATA_HOME=/tmp/gbmtest/ gbm and it totally works there. So it appears it has nothing to do with mono at all.

I tried it with Bejeweled 3 in both instances.

[basxto]

I looked up how to debug mono and run gbm as MONO_LOG_LEVEL=debug gbm. That gave me some interesting information.

It tries to run /usr/bin/xdg-open "/home/dabascht/Games/steam/steamapps/compatdata/78000/pfx/drive_c/users/steamuser/Local Settings/Application Data/Steam/Bejeweled3/users/" and /usr/bin/xdg-open "/home/dabascht/game_backup_monitor/savegames/Bejeweled 3/Bejeweled 3.7z"

If I run those commands on command lines, they hang. So xdg-open is the culprit, but the last update for xdg-utils was 09 Aug 2018. It has nothing to do with neither GBM nor mono, but I don’t know yet why xdg-open has trouble with those paths as it worked for the other GBM instance.

Here the debug output: (it first hangs after waiting on semaphore forever...)

Mono: Added SIGCHLD handler
Mono: process_create: Couldn't find executable /home/dabascht/Games/steam/steamapps/compatdata/78000/pfx/drive_c/users/steamuser/Local Settings/Application Data/Steam/Bejeweled3/users/
Mono: process_create: returning handle (nil) for pid 0
Mono: processes_cleanup
Mono: processes_cleanup done
Mono: process_create: Exec prog [/usr/bin/xdg-open] args ["/home/dabascht/Games/steam/steamapps/compatdata/78000/pfx/drive_c/users/steamuser/Local Settings/Application Data/Steam/Bejeweled3/users/"]
Mono: mono_w32handle_new: create Process handle 0x55933c31c4d8
Mono: mono_w32handle_ref_core: ref Process handle 0x55933c31c4d8, ref: 1 -> 2
Mono: mono_w32handle_ref_core: ref Process handle 0x55933c31c4d8, ref: 2 -> 3
Mono: mono_w32handle_unref_core: unref Process handle 0x55933c31c4d8, ref: 3 -> 2 destroy: false
Mono: process_create: child: parent has completed its setup
Mono: process_create: returning handle 0x55933c31c4d8 for pid 30024
Mono: processes_cleanup
Mono: processes_cleanup done
Mono: process_wait (0x55933c31c4d8, 4294967295)
Mono: process_wait (0x55933c31c4d8, 4294967295): PID: 30024
Mono: process_wait (0x55933c31c4d8, 4294967295): waiting on semaphore forever...
Mono: mono_w32handle_unref_core: unref Event handle 0x55933b600ab8, ref: 3 -> 2 destroy: false
Mono: mono_w32handle_unref_core: unref Event handle 0x55933b600ab8, ref: 2 -> 1 destroy: false
Mono: mono_w32handle_ref_core: ref Event handle 0x55933b600ab8, ref: 1 -> 2
Mono: ves_icall_System_Threading_Events_ResetEvent_internal: resetting Event handle 0x55933b600ab8
Mono: ves_icall_System_Threading_Events_ResetEvent_internal: no need to reset Event handle 0x55933b600ab8
Mono: mono_w32handle_unref_core: unref Event handle 0x55933b600ab8, ref: 2 -> 1 destroy: false
Mono: mono_w32handle_ref_core: ref Event handle 0x55933b600ab8, ref: 1 -> 2
Mono: mono_w32handle_test_capabilities: testing 0x3 against 0x8 (0)
Mono: mono_w32handle_test_capabilities: testing 0x3 against 0x1 (1)
Mono: mono_w32handle_test_capabilities: testing 0x3 against 0x4 (0)
Mono: mono_w32handle_timedwait_signal_handle: waiting for 0x55933b600ab8 (type Event)
Mono: mono_w32handle_ref_core: ref Event handle 0x55933b600ab8, ref: 2 -> 3

Mono: Added SIGCHLD handler
Mono: process_create: Exec prog [/home/dabascht/game_backup_monitor/savegames/Bejeweled 3/Bejeweled 3.7z] args []
Mono: process_create: Executable permisson not set on /home/dabascht/game_backup_monitor/savegames/Bejeweled 3/Bejeweled 3.7z
Mono: process_create: returning handle (nil) for pid 0
Mono: processes_cleanup
Mono: processes_cleanup done
Mono: process_create: Exec prog [/usr/bin/xdg-open] args ["/home/dabascht/game_backup_monitor/savegames/Bejeweled 3/Bejeweled 3.7z"]
Mono: mono_w32handle_new: create Process handle 0x562fcc5c3b28
Mono: mono_w32handle_ref_core: ref Process handle 0x562fcc5c3b28, ref: 1 -> 2
Mono: mono_w32handle_ref_core: ref Process handle 0x562fcc5c3b28, ref: 2 -> 3
Mono: mono_w32handle_unref_core: unref Process handle 0x562fcc5c3b28, ref: 3 -> 2 destroy: false
Mono: process_create: child: parent has completed its setup
Mono: process_create: returning handle 0x562fcc5c3b28 for pid 25775
Mono: processes_cleanup
Mono: processes_cleanup done
Mono: process_wait (0x562fcc5c3b28, 4294967295)
Mono: process_wait (0x562fcc5c3b28, 4294967295): PID: 25775
Mono: process_wait (0x562fcc5c3b28, 4294967295): waiting on semaphore forever...
Mono: mono_w32handle_unref_core: unref Event handle 0x562fcc5c3ab8, ref: 3 -> 2 destroy: false
Mono: mono_w32handle_unref_core: unref Event handle 0x562fcc5c3ab8, ref: 2 -> 1 destroy: false
Mono: mono_w32handle_ref_core: ref Event handle 0x562fcc5c3ab8, ref: 1 -> 2
Mono: ves_icall_System_Threading_Events_ResetEvent_internal: resetting Event handle 0x562fcc5c3ab8
Mono: ves_icall_System_Threading_Events_ResetEvent_internal: no need to reset Event handle 0x562fcc5c3ab8
Mono: mono_w32handle_unref_core: unref Event handle 0x562fcc5c3ab8, ref: 2 -> 1 destroy: false
Mono: mono_w32handle_ref_core: ref Event handle 0x562fcc5c3ab8, ref: 1 -> 2
Mono: mono_w32handle_test_capabilities: testing 0x3 against 0x8 (0)
Mono: mono_w32handle_test_capabilities: testing 0x3 against 0x1 (1)
Mono: mono_w32handle_test_capabilities: testing 0x3 against 0x4 (0)
Mono: mono_w32handle_timedwait_signal_handle: waiting for 0x562fcc5c3ab8 (type Event)
Mono: mono_w32handle_ref_core: ref Event handle 0x562fcc5c3ab8, ref: 2 -> 3

[MikeMaximus]

Ah ok, Thanks for looking into that and information about Mono debug mode.

I'm not sure why it would hang from one instance and not another. It looks like it may be attempting to throw an exception after "waiting on semaphore forever...", then just goes back to waiting again.

[basxto]

The freeze is normal, gbm waits until the child process is finished. When I click “Open Backup File” gbm is frozen until I close xarchiver. With my file manager it’s a bit different since it notifies an already running instance and closes itself.

With the temporary GBM instance I get

Mono: process_create: Exec prog [/usr/bin/xdg-open] args ["/tmp/gbmtest/savegame/Bejeweled 3/Bejeweled 3.7z"]

Mono: process_create: Exec prog [/usr/bin/xdg-open] args ["/home/dabascht/Games/steam/steamapps/compatdata/78000/pfx/drive_c/users/steamuser/Local Settings/Application Data/Steam/Bejeweled3/users/"]

But when I run the commands from the other GBM instance now, they work without hanging on command line.

[MikeMaximus]

Right sorry, that's normal since xdg-open is not ending.

I'll close this since it's related to xdg-open. But if you figure out why that instance is freezing i'd be interested to know.