comment #10:

> The program's behavior (or better stability) should not depend on arbitrary dialogs shown early enough at startup.

I fully agree. However, we don't know how to correct the issue at this point, so minimizing or eliminating the resulting effects would be an improvement.

I have been thinking this could be handled gracefully with another configuration option somewhat like the "global_skip_welcome_wizard". Let's call it "show_startup_version_dialog" with a default value of false to ensure the new dialog isn't displayed unless specifically enabled for backward compatibility. This flag would be checked immediately after the welcome wizard flag, and if it were set to true, it would cause Octave to display a simple modal dialog with an Octave icon, its version information, and an OK (or Close) button. The OK button would be simpler than setting up timers to close the dialog automatically after a fixed delay.

On the first run after installation, the welcome wizard would be displayed and the problem would be mitigated. On Windows installations where there is an issue, the new preference flag could be toggled by the user to mitigate the problem for future runs. Users on other platforms would not see the dialog unless they specifically asked for it.

Since this issue has already shown up in the file dialogs as well, it is possible, if not likely, that it will show up in other places until the underlying issue is identified and resolved. So this simple workaround may prevent other hangs as well.

Not sure if this can be related: Octave stores some configuration files (e.g., for the GUI layout) somewhere inside the user folder.
The path to that user folder usually contains the Windows user name. Windows allows many characters (including spaces or non-ASCII characters) in Windows user names. However, sometimes they cause issues with some tools, dependencies or assumptions in Octave itself.

@dennisc_hi: Does your Windows user name contain any non-ASCII characters or spaces by any chance?

comment #9:

> I repeat, displaying a Qt dialog, any dialog, early in the startup process (as when the welcome wizard displays its dialogs) completely prevents the hangs in the Qt File Dialogs and the documentation tab (and likely other places that have not been discovered yet). After that, everything works as expected.

That's understood, but would this be a solution? For me, this is exactly as if the Doctor says "don't do that" and therefore, only a workaround. The program's behavior (or better stability) should not depend on arbitrary dialogs shown early enough at startup.

comment #7:

> Both Qt and my system remain the exactly the same whether Octave executes the Welcome Wizard or not.

Showing the welcome wizard or not obviously trigger different paths in Qt- and/or Windows-libs.

comment #5:

> ... My system may be unique in that it exposes the problem in Octave ...

Yes, this is one possible explanation. But the problem might also be caused by Qt or by your system. Both issues show up where no Octave GUI code is directly involved (native file dialogs and Qt help system).

We just do not know what exactly breaks during the code sequence where the hidden console in the terminal is prepared. Btw, have you tried to set flag HIDDEN_CONSOLE in the terminal to false?

comment #3:

> @OP: how did you install Octave-9.2.0?

Using the Octave installer octave-9.2.0-w64-installer.exe from https://octave.org/download#ms-windows

comment #1:

> can similar debugging of the offending system call be done as I think you had help when trying to track down that other issue? perhaps this is slightly different or highlights some in-common function call?

What I did with the other issue was track down the location where displaying a dialog (rather than the welcome wizard's dialogs) no longer prevented the hangs from happening. I am fairly certain this will occur at the same location, as described in the forum discussions, since it is all in the initialization of the Command Window. This all happens before any user interaction.

I'm running Octave 9.2.0 GUI on Windows 10. I have the control (4.0.1) and signal (1.4.5) packages loaded from ~./octaverc.

If I click on the Documentation tab I see the Contents of the GNU Octave Manual. If I double-click on the heading for Chapter 31 Signal Processing in the left-hand list, the Octave GUI hangs and becomes Non-Responding (Windows adds the "Not Responding" text to the window's title bar). See the attached screenshot.

The memory usage of the Octave GUI starts climbing quite quickly. I captured two screenshots of the Windows task manager showing the memory usage about 5 seconds apart. See the attached screenshots which show that memory usage is increasing at about 100 MB/s.

I must click on the close box of the Octave GUI window to get a dialog where I can select to kill the program or wait for it to respond. I must kill the program before it exhausts all free memory on my PC to prevent many bad things from happening.

This behavior with the GUI becoming non-responsive and memory usage growing rapidly is very similar to the issue I have seen with the File Dialogs becoming non-responsive and memory usage growing. See the forum discussion discussing testing of that issue at https://octave.discourse.group/t/octave-9-1-file-dialogs-not-responding-on-windows-10/5413

In both cases, these issues are eliminated if the Octave GUI displays the Welcome Wizard (or any other dialogs early enough). I can force the Welcome Wizard to display its dialogs by editing the octave-gui.ini file and setting global_skip_welcome_wizard=false before starting Octave. In this case, the documentation for Signal Processing is displayed correctly, and in the other case, the File Dialogs work correctly and allow navigation.