bugGNU Octave - Bugs: bug #65312, "__run_test_suite__" ran...

 
 

bug #65312: "__run_test_suite__" ran in GUI hangs Octave in some configurations

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  Wed 14 Feb 2024 04:38:04 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * other Operating System:  * GNU/Linux
Fixed Release:  9.1.0 Planned Release:  9.1.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 29 Feb 2024 09:48:40 PM UTC, comment #51: 

Since the hang, and test failures with run.m, seem to have gone away, I'm going to close this bug as Fixed.

I do think it would be a good idea to only update the file browser when returning to the Octave prompt to eliminate a lot of unnecessary flashing displays and application slowdowns.  However, that deserves its own new bug report.

Rik <rik5>
Group administrator
Thu 29 Feb 2024 08:18:29 PM UTC, comment #50: 

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?

Torsten Lilge <ttl>
Group Member
Thu 29 Feb 2024 07:28:29 PM UTC, comment #49: 

I can not reproduce the test failure in "run" anymore.

Torsten Lilge <ttl>
Group Member
Thu 29 Feb 2024 06:21:58 AM UTC, comment #48: 

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.

Rik <rik5>
Group administrator
Thu 29 Feb 2024 05:59:49 AM UTC, comment #47: 

Dimitri, the commands give the following results:

$  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 is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_MACHZ_WDT=m

$ cat /boot/config-`uname -r` | grep HIGH_RES_TIMERS
CONFIG_HIGH_RES_TIMERS=y


Torsten Lilge <ttl>
Group Member
Thu 29 Feb 2024 12:09:29 AM UTC, comment #46: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Feb 2024 10:04:34 PM UTC, comment #45: 

I can confirm Torsten's observations in comment #40 on Windows with dev crossbuilds. I have been seeing this for ages.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 28 Feb 2024 04:40:45 AM UTC, comment #44: 

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.

John W. Eaton <jwe>
Group administrator
Wed 28 Feb 2024 03:58:50 AM UTC, comment #43: 

I just tested on Kubuntu 22.04 and I get no errors when using _run_test_suite_ and subsequently doing "test run".


Rik <rik5>
Group administrator
Tue 27 Feb 2024 11:32:23 PM UTC, comment #42: 

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

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 27 Feb 2024 10:01:03 PM UTC, comment #41: 

I cannot reproduce on Fedora 39 and Centos Stream 9 computers.

Summary:

  PASS                            18740
  FAIL                                0
  XFAIL (reported bug)               39
  SKIP (missing feature)             15
  SKIP (run-time condition)          29

...

>> test run
PASSES 5 out of 5 tests
>> test run
PASSES 5 out of 5 tests
>>


I will check on Ubuntus, but those are slow and it will take a while.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 27 Feb 2024 09:27:22 PM UTC, comment #40: 

_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


Torsten Lilge <ttl>
Group Member
Tue 27 Feb 2024 08:27:50 PM UTC, comment #39: 

Works for me (on Fedora 39) octave 9.0.91.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 27 Feb 2024 07:04:35 PM UTC, comment #38: 

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.

Rik <rik5>
Group administrator
Mon 19 Feb 2024 03:00:30 PM UTC, comment #37: 

Push?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 17 Feb 2024 08:16:06 AM UTC, comment #36: 

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

Torsten Lilge <ttl>
Group Member
Fri 16 Feb 2024 05:25:25 PM UTC, comment #35: 

Yes. With this patch it runs fine. I also do not see GLib-GIO-CRITICAL warnings any more.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Feb 2024 05:05:42 PM UTC, comment #34: 

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)

Markus Mützel <mmuetzel>
Group administrator
Fri 16 Feb 2024 08:11:15 AM UTC, comment #33: 

"It looks like the change from comment #16 was pushed to the default branch ... Was that intentional?"

No, that was a sloppy mistake on my part.  I backed out the changeset.

John W. Eaton <jwe>
Group administrator
Fri 16 Feb 2024 06:24:40 AM UTC, comment #32: 

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.

Markus Mützel <mmuetzel>
Group administrator
Fri 16 Feb 2024 06:17:02 AM UTC, comment #31: 

FWIW current dev (hgid 459ad9067f62) still hangs on Fedora 39.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 16 Feb 2024 05:46:51 AM UTC, comment #30: 

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.

Markus Mützel <mmuetzel>
Group administrator
Thu 15 Feb 2024 09:39:59 PM UTC, comment #29: 


comment #28:

> 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.
>


Not really. Attached is flatpak. 9.0.91 looks pretty much the same.

Dmitri.
--



Dmitri A. Sergatskov <dasergatskov>
Thu 15 Feb 2024 09:17:35 PM UTC, comment #28: 

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.

Torsten Lilge <ttl>
Group Member
Thu 15 Feb 2024 09:14:41 PM UTC, comment #27: 

If we add a preference, then the related text would have to be translated again, which is probably not desired direct before the final release. We could use the derived file icon provider on Linux (and MacOS?) and the QFileIconProvider on Windows.

I played around with icons that are selected depending on the mime type and used the following in the providers icon method:

    QMimeDatabase db;
    QMimeType type = db.mimeTypeForFile(fi.absoluteFilePath ());
    return QIcon::fromTheme (type.iconName ());

This already slows down the file browser as if the QFileIconProvider is used. Without calling QIcon::fromTheme, the file browser works as expected. Obviously, the delays that we are seeing are caused by searching the correct icon.

Torsten Lilge <ttl>
Group Member
Thu 15 Feb 2024 08:57:45 PM UTC, comment #26: 


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.
--



Dmitri A. Sergatskov <dasergatskov>
Thu 15 Feb 2024 07:16:39 AM UTC, comment #25: 

The following change essentially takes Torsten's idea but uses the default file icon provider for the cached icons:

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        Thu Feb 15 08:13:54 2024 +0100
@@ -177,6 +177,44 @@
   }
 };

+class cache_file_icon_provider : public QFileIconProvider
+{
+public:
+  cache_file_icon_provider ()
+  {
+    QFileIconProvider fip;
+    null_icon = QIcon ();
+    file_icon = fip.icon (QFileIconProvider::File);
+    folder_icon = fip.icon (QFileIconProvider::Folder);
+  }
+
+  QIcon icon (IconType ict) const
+  {
+    if (ict == QFileIconProvider::File)
+      return file_icon;
+    else if (ict == QFileIconProvider::Folder)
+      return folder_icon;
+    else
+      return null_icon;
+  }
+
+  QIcon icon (const QFileInfo &fi) const
+  {
+    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;
+
+};
+
 files_dock_widget::files_dock_widget (QWidget *p)
   : octave_dock_widget ("FilesDockWidget", p)
 {
@@ -315,6 +353,9 @@
   QModelIndex rootPathIndex
     = m_file_system_model->setRootPath (startup_dir.absolutePath ());

+  m_file_icon_provider = new cache_file_icon_provider ();
+  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        Thu Feb 15 08:13:54 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.
   //!@{


With icons that are cached that way, the test suite is still running fast for me. And icons are displayed for the files and folders in the file browser (with their default icons).

However, that change leads to a visual regression on systems where the default icon provider works fine: E.g., on Windows without this patch, .xlsx files are displayed with an Excel specific icon. With this patch, all files are displayed with the same default icon (a sheet of paper).

If we'd like to go with a patch like this, maybe we should have an option in the preferences to switch between the native file icon provider and the custom file icon provider (that can be much faster on some systems).

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 09:34:34 PM UTC, comment #24: 

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;

 };


Torsten Lilge <ttl>
Group Member
Wed 14 Feb 2024 09:07:51 PM UTC, comment #23: 

Markus, your patch solves all issues for me: slow down in _run_test_suite_ and delay in changing the directory (in the file browser or while running a script from the editor).

Torsten Lilge <ttl>
Group Member
Wed 14 Feb 2024 09:04:13 PM UTC, comment #22: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 08:36:47 PM UTC, comment #21: 

It really seems to be the icon provider that is causing this slowdown. With this dummy icon provider (that doesn't provide any icons), switching directories is as fast as with Qt5 and the test suite runs with regular speed:

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 21:32:05 2024 +0100
@@ -177,6 +177,29 @@
   }
 };

+class null_file_icon_provider : public QFileIconProvider
+{
+public:
+  null_file_icon_provider ()
+  {
+    null_icon = QIcon ();
+  }
+
+  QIcon icon (IconType) const
+  {
+    return null_icon;
+  }
+
+  QIcon icon (const QFileInfo &) const
+  {
+    return null_icon;
+  }
+
+private:
+  QIcon null_icon;
+
+};
+
 files_dock_widget::files_dock_widget (QWidget *p)
   : octave_dock_widget ("FilesDockWidget", p)
 {
@@ -315,6 +338,9 @@
   QModelIndex rootPathIndex
     = m_file_system_model->setRootPath (startup_dir.absolutePath ());

+  m_file_icon_provider = new null_file_icon_provider ();
+  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 21:32:05 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.
   //!@{


Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 08:20:09 PM UTC, comment #20: 

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.

John W. Eaton <jwe>
Group administrator
Wed 14 Feb 2024 08:18:23 PM UTC, comment #19: 
Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 08:11:23 PM UTC, comment #18: 

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.
--
 

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 07:55:23 PM UTC, comment #17: 


comment #15:

> It looks like you attached gdb to the wrapper executable that just gives up the controlling terminal (so "less" will work properly in the command widget) and then execs the real Octave process.  Instead, try attaching to the "octave-gui" process that is executed by the wrapper program


OK. see attached (gdb_all.txt.gz)

Dmitri.
--


(file #55702)

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 07:44:18 PM UTC, comment #16: 

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.

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 07:32:44 PM UTC, comment #15: 

"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: "

It looks like you attached gdb to the wrapper executable that just gives up the controlling terminal (so "less" will work properly in the command widget) and then execs the real Octave process.  Instead, try attaching to the "octave-gui" process that is executed by the wrapper program

John W. Eaton <jwe>
Group administrator
Wed 14 Feb 2024 07:31:05 PM UTC, comment #14: 

"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.


John W. Eaton <jwe>
Group administrator
Wed 14 Feb 2024 07:15:00 PM UTC, comment #13: 

The icon for files is missing in the file browser with Qt6. There is an icon on the left of every file with Qt5.
(An icon is displayed for every folder in both versions.)

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 07:12:26 PM UTC, comment #12: 

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.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 07:10:50 PM UTC, comment #11: 

Started a Ubuntu 23.10 VM and I'm seeing the same.

The file browser starts flashing during `__run_test_suite__`, sometimes it eventually stays blank, and the Octave process seems frozen.

@Dmitri: That is the expected behavior. The function returns the value that a property had before it is changed (to facilitate restoring the value afterwards).
But I noticed that changes to "filesdockwidget/sync_octave_directory" with that function don't have an effect until I restart Octave or I open and close the preferences dialog. I don't know if that is expected. (But like I wrote earlier, that approach is a workaround at best and doesn't actually solve the underlying issue.)

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 07:05:37 PM UTC, comment #10: 

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.

Torsten Lilge <ttl>
Group Member
Wed 14 Feb 2024 06:56:24 PM UTC, comment #9: 

And the same with "true":

>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false")
ans = false
>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "true")
ans = false
>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "true")
ans = true
>>


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 06:55:13 PM UTC, comment #8: 

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..."

Torsten Lilge <ttl>
Group Member
Wed 14 Feb 2024 06:54:29 PM UTC, comment #7: 

I have noticed this (starting with the option checked):

>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false")
ans = true
>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false")
ans = false
>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false")
ans = false
>> __event_manager_gui_preference__ ("filesdockwidget/sync_octave_directory", "false")
ans = false


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 06:19:19 PM UTC, comment #6: 

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?

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 05:58:09 PM UTC, comment #5: 

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

With this patch it hangs the same.

Dmitri.
--




Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 05:20:33 PM UTC, comment #4: 

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?)

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 05:17:54 PM UTC, comment #3: 

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

Yes, I found the same.  I'm still not sure why this is not an issue if I build with Qt5 on the same system.

John W. Eaton <jwe>
Group administrator
Wed 14 Feb 2024 04:50:02 PM UTC, comment #2: 

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

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 04:43:54 PM UTC, comment #1: 

The GLib-GIO-CRITICAL warnings appear to come from File Browser.
Is there a way to disable it or disable its attempts to "refresh"?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 04:38:04 PM UTC, original submission:  

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.
--

Dmitri A. Sergatskov <dasergatskov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55708:  octave_flatpak.png added by dasergatskov (116KiB - image/png)
file #55702:  gdb_all.txt.gz added by dasergatskov (10KiB - application/gzip)
file #55698:  str2.log.gz added by dasergatskov (3KiB - application/gzip)
file #55699:  fntests.log added by dasergatskov (2KiB - text/x-log)
file #55697:  hang2.png added by dasergatskov (912KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-02-29 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 9.1.0
    2024-02-27 rik5 StatusNone Ready For Test
        Fixed ReleaseNone 9.1.0
    2024-02-16 mmuetzel Attached File- Added bug65312-file-icon-cache.patch, #55709
    2024-02-15 dasergatskov Attached File- Added octave_flatpak.png, #55708
    2024-02-14 dasergatskov Attached File- Added gdb_all.txt.gz, #55702
    2024-02-14 dasergatskov Attached File- Added hang2.png, #55697
        Attached File- Added str2.log.gz, #55698
        Attached File- Added fntests.log, #55699

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code