I would like to support John's suggestion to update the file browser only when the prompt is displayed again. This sounds somehow familiar to me, wasn't this the update strategy during the "early years" of the GUI?

Maybe you can debug this directly.  Execute '__run_test_suite__' first.  Then, before doing 'test run', edit run.m to put a "keyboard;" statement within the BIST test right at the start.  Now execute 'test run'.  Use 'dbnext' to advance line-by-line and see if you can discover what the problem is.  My guess is that there is leftover files from the previous run somehow.

I wonder if this related to
https://savannah.gnu.org/bugs/?65018
(and 40117)

Torsten, do you have hi-res timer enabled on your computer?
You can check it e.g. as:

$ cat /boot/config-`uname -r` | grep HZ
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_MACHZ_WDT is not set
$ cat /boot/config-`uname -r` | grep HIGH_RES_TIMERS
CONFIG_HIGH_RES_TIMERS=y

Dmitri.
--

I was still seeing a significant slowdown when executing _run_test_suite_ in the GUI.  While trying to debug where the delay was happening, I noticed that the GUI was looking for icons for files in /tmp.  I happened to have about 10,000 junk files there.  Oops!  Performance improved when I removed them.  That's good, but I don't think performance should be terrible just because you happen to cd to a directory that contains many files, especially if that is happening while running a script.

Maybe we should limit the updates of the file browser to the current directory when the prompt is displayed and not attempt to follow every directory change that happens while a script or function is executing?  Even if we agree that's a reasonable thing to do, I don't think we need to delay the release for it.

Do not see the problem on Ubuntu 23.10 (x86_64 and aarch64).

Dmitri.
--

_run_test_suite_ shows normal performance. However, there is a failed test for "run", although I do not think this is related to the patch. It only occurs during and after _run_test_suit_, not after a fresh start of Octave.

>> test run
***** test
 path_orig = path ();
 tmp_dir = tempname ();
 test_function = fullfile (tmp_dir, "tf.m");
 unwind_protect
   mkdir (tmp_dir);
   fid = fopen (test_function, "w");
   fprintf (fid, "function tf ()\n");
   fprintf (fid, "  addpath ('%s');\n", tmp_dir);
   fprintf (fid, "endfunction\n");
   fclose (fid);
   ## Check if temporary directory is on the loadpath.
   ## Function 'dir_in_loadpath' is broken for this use case, so code a test.
   dirs = strsplit (path (), pathsep ());
   tstval1 = any (is_same_file (tmp_dir, dirs));
   run (test_function);
   dirs = strsplit (path (), pathsep ());
   tstval2 = any (is_same_file (tmp_dir, dirs));
   assert (tstval1, false);
   assert (tstval2, true);
 unwind_protect_cleanup
   unlink (test_function);
   sts = rmdir (tmp_dir);
   path (path_orig);
 end_unwind_protect
!!!!! test failed
ASSERT errors for:  assert (tstval2,true)

  Location  |  Observed  |  Expected  |  Reason
     ()           0            1         Abs err 1 exceeds tol 0 by 1

I pushed the changeset with a commit message to stable here: https://hg.savannah.gnu.org/hgweb/octave/rev/dbf49a4f50da

Marking as Ready for Test.

I can also confirm that with your patch, the file browser is reactive again and specific icons are shown for some mime types.

The attached patch caches the file icons (thus reducing calls to QIcon::fromTheme to a minumum).

With it, the test suite runs fast on Ubuntu with Qt6.
Also, the file specific icons are still shown on Windows and for Libre Office files on Ubuntu.

Does that solve the hangs for you, too?




(file #55709)

The change from comment #16 just made a visual difference: icons appear on some systems where they didn't appear before. No changes with respect to the slow down. So, I wouldn't have expected that anything changed with respect to Octave getting slow or stuck.

It looks like the change from comment #16 was pushed to the default branch as part of the following change:
https://hg.savannah.gnu.org/hgweb/octave/rev/489026b7257b

Was that intentional? If it was, we should probably "graft" that part of the change to the stable branch.

Dimitri, at least for office files, you should see the correct icons. On Debian/Gnome I also see this plain icon for several file types including graphics files but the correct icon for office and other special files.

comment #25:

> all files are displayed with the same default icon (a sheet of paper).

This is what I currently see on an un-affected system (Centos  Stream 9) with octave 7.3 (provided by repo) and 9.0.91 (self-compiled against either Qt6-6.5.2 or Qt5.15.9) and 8.4.0 (flatpak).

Dmitri.
--

This slight extension of Markus' file icon provider (patch on top of Markus' one) returns folder and file icons from the current icon theme (the latter not optimal, it is the "document-new" icon).

diff -r 5e6bdf6ad817 libgui/src/files-dock-widget.cc
--- a/libgui/src/files-dock-widget.cc   Wed Feb 14 22:01:08 2024 +0100
+++ b/libgui/src/files-dock-widget.cc   Wed Feb 14 22:31:08 2024 +0100
@@ -182,21 +182,36 @@ class null_file_icon_provider : public Q
 public:
   null_file_icon_provider ()
   {
+    gui_settings settings;
+    file_icon = settings.icon ("document-new");
+    folder_icon = settings.icon ("folder");
     null_icon = QIcon ();
   }

-  QIcon icon (IconType) const
+  QIcon icon (IconType ict) const
   {
-    return null_icon;
+    if (ict == QAbstractFileIconProvider::File)
+      return file_icon;
+    else if (ict == QAbstractFileIconProvider::Folder)
+      return folder_icon;
+    else
+      return null_icon;
   }

-  QIcon icon (const QFileInfo &) const
+  QIcon icon (const QFileInfo &fi) const
   {
-    return null_icon;
+    if (fi.isFile ())
+      return file_icon;
+    else if (fi.isDir ())
+      return folder_icon;
+    else
+      return null_icon;
   }

 private:
   QIcon null_icon;
+  QIcon file_icon;
+  QIcon folder_icon;

 };

It looks to me that we have some underlying problem in octave code (thread contention?) that exposed by either GLib issues on Fedora
or Qt6 issues (icon provider) on Debian.

I do not see a slow-down -- it either hangs or not.
it also hangs for me on Qt5.

Dmitri.
--

Markus:  Setting the preference from the command line seems to work and avoided the _run_test_suite_ problem for me.  The file browser wasn't updating when it ran and I started with the item checked in the settings dialog.

If I use the dialog to disable the file browser sync feature, then _run_test_suite_ takes about 4 minutes on my system and the file browser is not updating as the script runs.

If I use your patch and start with the file browser sync feature enabled, it takes about 14 minutes to run and the file browser is updating.  I checked the dialog while the tests are running and the box is not checked.  Strange.

If I start octave as:

QT_QPA_PLATFORMTHEME=gnome octave --gui

(found here:
https://discussion.fedoraproject.org/t/neovim-qt-qgtk3theme-glib-gio-critical-errors/95633/2
)
then GLib-GIO-CRITICAL disappear and _run_test_suite_ appears to run fine. May be it just circumvents the issue though...

Dmitri.
--
 

The following change makes the icons appear for me:

diff -r 92a2e883af17 libgui/src/files-dock-widget.cc
--- a/libgui/src/files-dock-widget.cc        Wed Feb 14 15:07:28 2024 +0100
+++ b/libgui/src/files-dock-widget.cc        Wed Feb 14 20:42:16 2024 +0100
@@ -315,6 +315,9 @@
   QModelIndex rootPathIndex
     = m_file_system_model->setRootPath (startup_dir.absolutePath ());

+  m_file_icon_provider = new QFileIconProvider ();
+  m_file_system_model->setIconProvider (m_file_icon_provider);
+
   // Attach the model to the QTreeView and set the root index
   m_file_tree_view = new FileTreeViewer (container);
   m_file_tree_view->setSelectionMode (QAbstractItemView::ExtendedSelection);
diff -r 92a2e883af17 libgui/src/files-dock-widget.h
--- a/libgui/src/files-dock-widget.h        Wed Feb 14 15:07:28 2024 +0100
+++ b/libgui/src/files-dock-widget.h        Wed Feb 14 20:42:16 2024 +0100
@@ -29,6 +29,7 @@
 #include <QAction>
 #include <QComboBox>
 #include <QDate>
+#include <QFileIconProvider>
 #include <QFileSystemModel>
 #include <QList>
 #include <QListView>
@@ -210,6 +211,7 @@
   //! The file system model.

   QFileSystemModel *m_file_system_model;
+  QFileIconProvider *m_file_icon_provider;

   //! The file system view.
   //!@{

But the test suite still feels slower than usual.

"journalctl | grep -i glib" shows nothing on my system.

When I was first trying to debug the hangs, I attached gdb to teh Octave process and saw that it was often in this state:

(gdb) where
#0  __GI___access (file=0x55f33e49adb0 "/home/jwe/.local/share/icons/hicolor/22x22/stock/table/application-octet.png", type=0)
    at ../sysdeps/unix/sysv/linux/access.c:27
#1  0x00007ff62ba61035 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#2  0x00007ff62b900770 in QFileInfo::exists(QString const&) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#3  0x00007ff62bf3a25b in QIconLoader::findIconHelper(QString const&, QString const&, QList<QString>&) const () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#4  0x00007ff62bf3bf82 in QIconLoader::loadIcon(QString const&) const () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#5  0x00007ff62bf3c153 in ?? () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#6  0x00007ff62bf3c38c in ?? () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#7  0x00007ff62bf2f867 in QIcon::fromTheme(QString const&) () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#8  0x00007ff62bf26e22 in QAbstractFileIconProviderPrivate::getIconThemeIcon(QFileInfo const&) const () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#9  0x00007ff62bf2b026 in QAbstractFileIconProvider::icon(QFileInfo const&) const () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#10 0x00007ff62c2ace69 in QFileInfoGatherer::getInfo(QFileInfo const&) const () from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#11 0x00007ff62c2c17c9 in QFileSystemModelPrivate::_q_fileSystemChanged(QString const&, QList<std::pair<QString, QFileInfo> > const&) ()
   from /lib/x86_64-linux-gnu/libQt6Gui.so.6
#12 0x00007ff62b9723b0 in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#13 0x00007ff62c782d22 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#14 0x00007ff62fa0f393 in octave::octave_qapplication::notify (this=0x55f33d1a19b0, receiver=<optimized out>, ev=<optimized out>)
    at /home/jwe/src/octave/libgui/src/octave-qobject.cc:150
#15 0x00007ff62b9353f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#16 0x00007ff62b9355d7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt6Core.so.6

The file it appears to be looking for doesn't exist on my system.  I don't know why it would hang there, if it was.  But that traceback showed up repeatedly and it seems unlikely that I would randomly catch it there multiple times if it wasn't stuck or waiting for something.

About GLib-GIO-CRITICAL. It looks like on some systems those floods systemlogs. Torsten Lilge <ttl> and John W. Eaton <jwe>, could you check your systemlogs (journalctl)?

Dmitri.
--

When just selecting a directory in the file browsers history, this might take several seconds until the directory is shown. It looks like the more files are in the new directory, the longer the delay until it is shown.

I can confirm that the delay of approx. 5s when running a script from the editor (and the file is not yet in the search path and you select "Change Directory"), also disappears when unchecking "Synchronize Octave working directory..."

Did the file browser still change to the directory with the current tests while the test suite was running?

If you run the following from the Octave prompt (while the "Synchronize Octave working directory..." setting is still active), does it still hang? Does the directory in the file browser still change?

__event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false")
__run_test_suite__

Is the "Synchronize..." setting still selected after that?

Nice catch!

I also thought sometimes that the GUI and the interpreter are "fighting" over the current working directory if it changes often.

Does the following change avoid the issue for you? Also with checked "Synchronize Octave working directory..."?

diff -r 92a2e883af17 scripts/testfun/__run_test_suite__.m
--- a/scripts/testfun/__run_test_suite__.m        Wed Feb 14 15:07:28 2024 +0100
+++ b/scripts/testfun/__run_test_suite__.m        Wed Feb 14 18:14:39 2024 +0100
@@ -56,12 +56,19 @@
   orig_wquiet = warning ("query", "quiet");
   orig_wstate = warning ();
   orig_mfile_encoding = mfile_encoding ("utf-8");
+  if (isguirunning ())
+    orig_sync_dir = ...
+      __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory");
+  endif
   logfile = make_absolute_filename ("fntests.log");
   unwind_protect
     page_screen_output (false);
     warning ("on", "quiet");
     warning ("off", "Octave:deprecated-function");
     warning ("off", "Octave:legacy-function");
+    if (isguirunning ())
+      __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false");
+    endif
     nfail = dp = dn = dxf = dxb = dsk = drtsk = drgrs = 0;
     try
       fid = fopen (logfile, "wt");
@@ -157,6 +164,9 @@
     warning ("off", "all");
     warning (orig_wstate);
     warning (orig_wquiet.state, "quiet");
+    if (isguirunning ())
+      __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", orig_sync_dir);
+    endif
     mfile_encoding (orig_mfile_encoding);
     page_screen_output (pso);
   end_unwind_protect

This just treads the symptom. I don't know where the actual issue would need to be fixed. (Maybe, it's a race condition for changing the directory from the interpreter thread and the GUI thread?)

If I un-check "Synchronize Octave working directory..." in the File Browser settings, _run_test_suite_ does not hang and runs normally.

Dmitri.
--

On current Fedora 39, "__run_test_gui__" would hang octave with 100% reproducibility. I observed that on AMD FX-8350, i9-9880H, and on Raspberry PI 4 (aarch64). The desktop has to be GNOME, the
run completes w/o problem on GTK. The run also completes fine if I started GUI with "--experimental-terminal-widget".
This happens with both octave 8.4.0 (as supplied by Fedora repo) and with self-compiled 9.0.91 (with different compilers and compilation flags including -O0).

When octave started from Gnome terminal as "octave --gui" the octave's CommandWindow is flooded with

 (octave-gui:68826): GLib-GIO-CRITICAL **: 20:21:28.119: file ../gio/gfileinfo.c: line 1766 (g_file_info_get_icon): should not be reached

(octave-gui:68826): GLib-GIO-CRITICAL **: 20:21:28.120: GFileInfo created without standard::icon

(octave-gui:68826): GLib-GIO-CRITICAL **: 20:21:28.120: file ../gio/gfileinfo.c: line 1766 (g_file_info_get_icon): should not be reached

(octave-gui:68826): GLib-GIO-CRITICAL **: 20:21:28.120: GFileInfo created without standard::icon

(octave-gui:68826): GLib-GIO-CRITICAL **: 20:21:28.120: file ../gio/gfileinfo.c: line 1766 (g_file_info_get_icon): should not be reached

warnings. They are continue to pop-up in large numbers during the "__run_test_suite__" execution. After a short time octave GUI becomes frozen and non-responsive (see attached screenshot "hang2.png"). GUI hangs at/after execution of oct-inttypes.cc-tst, yet fntests.log indicates that there are few more test have finished (see attached fntests.log). The number of those "extra' tests varies, whne compiled with "-O2" it finishes only one more test (Cell.cc-tst).

I have run "strace octave --gui 2> str2.log; str2log.gz is attached.
I have also tried to attach gdb to a frozen octave process. Here is what I see there:

 26      __wait4_time64 (pid_t pid, int *stat_loc, int options, struct __rusage64 *usage)
27      {
28      #ifdef __NR_wait4
29      # if __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64
30        return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
31      # else
32        pid_t ret;
33        struct __rusage32 usage32;
34
(gdb) thread apply all bt

Thread 1 (Thread 0x7fa5ce8737c0 (LWP 319859) "octave"):
#0  0x00007fa5ce43bd27 in __GI___wait4 (pid=319860, stat_loc=0x7ffd79cd5f60, options=0, usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x00007fa5ce43be6b in __GI___waitpid (pid=<optimized out>, stat_loc=<optimized out>, options=<optimized out>) at waitpid.c:38
#2  0x00000000004044e0 in octave_waitpid_wrapper (pid=<optimized out>, statusp=<optimized out>, options=<optimized out>) at ../liboctave/wrappers/wait-wrappers.c:101
#3  0x00000000004033e8 in main (argc=2, argv=0x7ffd79cd6178) at src/main.cc:525
(gdb)

Dmitri.
--