bugGNU Octave - Bugs: bug #65866, make check: Fatal segmentation...

 
 

bug #65866: make check: Fatal segmentation fault when running image/getframe.m test

Submitter:  Atri Bhattacharya <badshah400>
Submitted:  Mon 10 Jun 2024 09:52:47 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Ready For Test Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 9.1.0 Release: 
Operating System:  * Any Fixed Release:  None
Planned Release:  10.3.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Jun 2025 07:04:32 PM UTC, comment #24: 

Thanks again for the patch.
I split it into two (more or less unrelated parts), added commit messages and pushed them after some minor changes to the stable branch:
https://hg.savannah.gnu.org/hgweb/octave/rev/bba7d206cd35
https://hg.savannah.gnu.org/hgweb/octave/rev/d8c7494d661f

I didn't realize before that the change in image.m is pretty uncontroversial. If I had, we could probably have included that part in Octave 10.2.

The "actual" fix is the second changeset. If that should cause trouble, we could just revert that part.

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Mon 26 May 2025 03:01:08 PM UTC, comment #23: 

Whole lotta thanks for figuring this out, Dmitri. Looking fwd to applying your patch atop version 10.2 when it is released for our  (openSUSE) rpm packages.

Atri Bhattacharya <badshah400>
Fri 23 May 2025 06:01:11 PM UTC, comment #22: 

I think for colordepth < 16 we should set "have_window_system" to 0. Qt actually wants 24 (https://doc.qt.io/qt-6/qopenglwidget.html):
<<<<

Note: Displaying a QOpenGLWidget requires an alpha channel in the associated top-level window's backing store due to the way composition with other QWidget-based content works. If there is no alpha channel, the content rendered by the QOpenGLWidget will not be visible. This can become particularly relevant on Linux/X11 in remote display setups (such as, with Xvnc), when using a color depth lower than 24. For example, a color depth of 16 will typically map to using a backing store image with the format QImage::Format_RGB16 (RGB565), leaving no room for an alpha channel. Therefore, if experiencing problems with getting the contents of a QOpenGLWidget composited correctly with other the widgets in the window, make sure the server (such as, vncserver) is configured with a 24 or 32 bit depth instead of 16.

>>>>


Currently (at 8-bit) all plotting is broken and what worse it is
often silently broken, e.g. "plot(1:3); print t1.svg" produces no error and no output file. But I do not think this should be fixed piecemeal.

Anyway.
I added FIXME:


+    if (isempty (cdata))
+      error ("getframe: failed to capture frame data, possibly due to insufficient graphics capabilities");
+    ## FIXME: We should not be here. The graphics subsystem is inadequate. This should have been detected
+    ##        and "have_window_system" set to 0 earlier.
+    endif
+


The full diff is attached (file getframe_fix1.diff)

Dmitri.
--


(file #57239)

Dmitri A. Sergatskov <dasergatskov>
Fri 23 May 2025 09:39:42 AM UTC, comment #21: 

Thank you very much for the proposed changes.

I'd say that emitting an error would probably be the "correct thing" to do here. After all, we find ourselves in a situation where "getframe" can't do anything useful.
Maybe, also add a FIXME note that says that it would be nice to be able to tell beforehand if _get_frame_ will fail because of an uninitialized OpenGL context. (Addressing that would probably happen on the default branch.)

jwe and I briefly talked about this during the office hour yesterday. We are unsure if this change could have any unexpected side effects. And since the release of Octave 10.2.0 is imminent, we'd prefer to not "rush" this in.
After all, the issue only occurs in very specific scenarios that very likely only occur in automated build and test environments and probably won't affect many end users. (And it can be worked around by setting a high enough color depth of the virtual display in these automated environments.)

But it is a segmentation fault that we can avoid. So, we should do that (on the stable branch). But we'd prefer to wait until after the release of Octave 10.2.0 so that we have a little more time to get reports from testers in case the fix has any unexpected side effects.
There is not yet a value of 10.3.0 for the "Planned Release" field. But if there were, I'd set it to that.

Markus Mützel <mmuetzel>
Group administrator
Thu 22 May 2025 06:41:47 PM UTC, comment #20: 


diff -r 676ecf184d8a scripts/image/getframe.m
--- a/scripts/image/getframe.m  Thu May 22 18:48:44 2025 +0200
+++ b/scripts/image/getframe.m  Thu May 22 14:39:01 2025 -0400
@@ -111,6 +111,11 @@
     units = get (hf, "units");
     set (hf, "units", "pixels");
     cdata = __get_frame__ (hf);
+
+    if (isempty (cdata))
+      warning ("getframe: failed to capture frame data, possibly due to insufficient graphics capabilities");
+    endif
+
   unwind_protect_cleanup
     set (hf, "units", units)
   end_unwind_protect


Looks useful in general. (Should it be "error" instead of "warning"?)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 22 May 2025 06:31:17 PM UTC, comment #19: 

With diff:

diff -r 676ecf184d8a libgui/graphics/GLCanvas.cc
--- a/libgui/graphics/GLCanvas.cc       Thu May 22 18:48:44 2025 +0200
+++ b/libgui/graphics/GLCanvas.cc       Thu May 22 14:22:04 2025 -0400
@@ -68,7 +68,7 @@
 {
   if (go)
     {
-      begin_rendering ();
+      if (! begin_rendering ()) return;

       unwind_action reset_current ([this] () { end_rendering (); });

@@ -93,7 +93,7 @@
       pos(2) *= dpr;
       pos(3) *= dpr;

-      begin_rendering ();
+      if (! begin_rendering ()) return uint8NDArray ();

       unwind_action reset_current ([this] () { end_rendering (); });

@@ -136,7 +136,7 @@
 {
   if (go.valid_object ())
     {
-      begin_rendering ();
+      if (! begin_rendering ()) return;

       unwind_action reset_current ([this] () { end_rendering (); });

@@ -173,7 +173,7 @@
 {
   if (ax)
     {
-      begin_rendering ();
+      if (! begin_rendering ()) return graphics_object ();

       unwind_action reset_current ([this] () { end_rendering (); });

@@ -200,7 +200,7 @@
   double borderalpha = 0.9;
   double borderwidth = 1.5;

-  begin_rendering ();
+  if (! begin_rendering ()) return;

   unwind_action reset_current ([this] () { end_rendering (); });

diff -r 676ecf184d8a scripts/image/image.m
--- a/scripts/image/image.m     Thu May 22 18:48:44 2025 +0200
+++ b/scripts/image/image.m     Thu May 22 14:22:04 2025 -0400
@@ -146,17 +146,17 @@

 function h = __img__ (hax, do_new, x, y, img, varargin)

+  ## Initialize xdata and ydata to handle empty img case
+  xdata = [];
+  ydata = [];
+
   if (! isempty (img))

-    if (isempty (x))
-      xdata = [];
-    else
+    if (! isempty (x))
       xdata = x([1, end])(:).';  # (:).' is a hack to guarantee row vector
     endif

-    if (isempty (y))
-      ydata = [];
-    else
+    if (! isempty (y))
       ydata = y([1, end])(:).';
     endif


I get:

octave:1> test getframe verbose
>>>>> /home/uu1/src/dev/octave/scripts/image/getframe.m
***** demo
 clf;
 contourf (rand (5));
 drawnow ();
 frame = getframe ();
 imshow (frame.cdata);
Press <enter> to continue:
***** demo
 clf reset;
 contourf (rand (5));
 frame = getframe (gcf ());
 imshow (frame.cdata);
 set (gca, "position", [0 0 1 1]);
Press <enter> to continue:
***** demo
 clf;
 hax1 = subplot (2,1,1);
 contourf (rand (5));
 title ("Original");
 frame = getframe (hax1);
 hax2 = subplot (2,1,2);
 image (frame.cdata);
 title ("Frame");
Press <enter> to continue:
***** demo
 clf;
 hax1 = subplot (2,1,1);
 contourf (rand (5));
 title ("Original");

 ## Get the coordinates of the lower-left hand corner in pixels
 set (hax1, "units", "pixels");
 pos = get (hax1, "position");
 set (hax1, "units", "normalized");
 rect = [pos(1:2) pos(3:4)/2];

 frame = getframe (hax1, rect);
 hax2 = subplot (2,1,2);
 image (frame.cdata);
 title ("Lower left hand corner");
Press <enter> to continue:
***** testif HAVE_OPENGL, HAVE_QT; have_window_system () && any (strcmp ("qt", graphics_toolkit ()))
 hf = figure ("visible", "off");
 graphics_toolkit (hf, "qt");
 unwind_protect
   pos = get (hf, "position");
   dpr = get (hf, "__device_pixel_ratio__");
   assert (size (getframe (hf).cdata)(1:2), pos(4:-1:3)*dpr);
 unwind_protect_cleanup
   close (hf);
 end_unwind_protect
!!!!! test failed
ASSERT errors for:  assert (size (getframe (hf).cdata) (1:2),pos (4:-1:3) * dpr)

  Location  |  Observed  |  Expected  |  Reason
    (1)           0           420        Abs err 420 exceeds tol 0 by 4e+02
    (2)           0           560        Abs err 560 exceeds tol 0 by 6e+02
octave:2>

because

octave:6> getframe (hf)
ans =

  scalar structure containing the fields:

    cdata = [](0x0)
    colormap = [](0x0)

Not sure if this is good enough, or `getframe` should issue an error.
In any case I think it is better than a crash.
May be we apply this to stable and improve further on dev.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 22 May 2025 05:19:51 PM UTC, comment #18: 

I googled around and it looks like though OpenGL can technically work with 8-bit display (there is "GL_EXT_paletted_texture") most implementations expect at least 16-bit colordepth.
E.g. I see:

$ xvfb-run -s '-screen 0 640x480x8' glxinfo -B
name of display: :99
Error: couldn't find RGB GLX visual or fbconfig

$ xvfb-run -s '-screen 0 640x480x16' glxinfo -B
name of display: :99
display: :99  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa (0xffffffff)
    Device: llvmpipe (LLVM 19.1.7, 128 bits) (0xffffffff)
    Version: 25.0.3
    Accelerated: no
    Video memory: 7934MB
...


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 22 May 2025 04:48:01 PM UTC, comment #17: 

Alternatively or additionally, `have_window_system ()` should maybe return `false` in that case.
Or if that isn't the right thing, we might need something like `have_opengl ()` that indicates whether we can successfully initialize an OpenGL context. That function could be called, e.g., from inside `getframe` to emit an error if it couldn't be successfully initialized.


Markus Mützel <mmuetzel>
Group administrator
Thu 22 May 2025 04:37:44 PM UTC, comment #16: 

If that happens, it probably means that we couldn't draw anything at all.
But I know too little about this code to predict which changes would be necessary. I'm not sure whether these simple changes would be enough.

I'd guess that some restructuring(?) would be needed to allow `octave::GLCanvas::do_getPixels` or `octave::GLWidget::do_getPixels` to return early (returning what?) to avoid hitting this segmentation fault.

Markus Mützel <mmuetzel>
Group administrator
Thu 22 May 2025 04:29:30 PM UTC, comment #15: 

I need to setup a different computer for a reproducer, I cannot reboot to runlevel 3 on my workstation all the time.
(And Ubuntu 25.04 is broken on my Core2 laptop)

I see the check may be needed in 3 places in GLCanvas.cc:
In GLWidget::do_print, GLWidget::selectFromAxes, GLWidget::drawZoomBox .

I assume the diff like (in all three places):

-  begin_rendering ();
+  if (! begin_rendering ()) return;

should work?

May be we should re-open this bug.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 22 May 2025 03:18:59 PM UTC, comment #14: 


> #3  QOpenGLContext::format (this=0x0) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/gui/kernel/qopenglcontext.cpp:849


"this=0x0" looks suspicious.

Maybe, that means that the QOpenGLContext wasn't or couldn't be initialized?

Iiuc, `GLWidget::begin_rendering` would be returning `false` in that case (defined in libgui/Canvas/GLCanvas.cc). But afaict, we never check the return value of that function. Should we?

Markus Mützel <mmuetzel>
Group administrator
Thu 22 May 2025 03:05:50 PM UTC, comment #13: 

Here is the log:

>>>>> /home/dmitri/src/das_print/octave/scripts/image/getframe.m
***** demo
 clf;
 contourf (rand (5));
 drawnow ();
 frame = getframe ();
 imshow (frame.cdata);
warning: opengl_texture::create: the opengl library in use doesn't support images with either dimension larger than -1084733587. Not rendering.
warning: called from
    getframe at line 113 column 5
    __test__ at line 6 column 2
    test at line 385 column 13

Press <enter> to continue: ***** demo
 clf reset;
 contourf (rand (5));
 frame = getframe (gcf ());
 imshow (frame.cdata);
 set (gca, "position", [0 0 1 1]);
Press <enter> to continue: ***** demo
 clf;
 hax1 = subplot (2,1,1);
 contourf (rand (5));
 title ("Original");
 frame = getframe (hax1);
 hax2 = subplot (2,1,2);
 image (frame.cdata);
 title ("Frame");
Press <enter> to continue: ***** demo
 clf;
 hax1 = subplot (2,1,1);
 contourf (rand (5));
 title ("Original");

 ## Get the coordinates of the lower-left hand corner in pixels
 set (hax1, "units", "pixels");
 pos = get (hax1, "position");
 set (hax1, "units", "normalized");
 rect = [pos(1:2) pos(3:4)/2];

 frame = getframe (hax1, rect);
 hax2 = subplot (2,1,2);
 image (frame.cdata);
 title ("Lower left hand corner");
Press <enter> to continue: ***** testif HAVE_OPENGL, HAVE_QT; have_window_system () && any (strcmp ("qt", graphics_toolkit ()))
 hf = figure ("visible", "off");
 graphics_toolkit (hf, "qt");
 unwind_protect
   pos = get (hf, "position");
   dpr = get (hf, "__device_pixel_ratio__");
   assert (size (getframe (hf).cdata)(1:2), pos(4:-1:3)*dpr);
 unwind_protect_cleanup
   close (hf);
 end_unwind_protect
fatal: caught signal Segmentation fault -- stopping myself...

"doesn't support images with either dimension larger than -1084733587" suggests some signed/un-signed mismatch. Perhaps we should look for that.

The coredump is attached (file  coredump_getframe.txt.gz).
The relevant part:

Thread 1 (Thread 0x7f5fbed70b40 (LWP 2344)):
#0  0x00007f5fcbcf0a5d in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::get (this=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/tools/qscopedpointer.h:112
#1  qGetPtrHelper<QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > const> (ptr=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/global/qtclasshelpermacros.h:137
#2  QOpenGLContext::d_func (this=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/gui/kernel/qopenglcontext.h:69
#3  QOpenGLContext::format (this=0x0) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/gui/kernel/qopenglcontext.cpp:849
#4  0x00007f5fcbcf0b58 in QOpenGLContext::isOpenGLES (this=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/gui/kernel/qopenglcontext.cpp:935
#5  0x00007f5fccd6940d in effectiveInternalFormat (internalFormat=0) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/opengl/qopenglframebufferobject.cpp:895
#6  effectiveInternalFormat (internalFormat=0) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/opengl/qopenglframebufferobject.cpp:889
#7  QOpenGLFramebufferObject::QOpenGLFramebufferObject (this=0x7ffef7b76b00, width=560, height=420, attachment=QOpenGLFramebufferObject::Depth, target=3553, internalFormat=0) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/opengl/qopenglframebufferobject.cpp:986
#8  0x00007f5fccf7180f in octave::GLWidget::do_getPixels (this=this@entry=0x2cc81180, go=...) at ../libgui/graphics/GLCanvas.cc:107
#9  0x00007f5fccf75918 in octave::GLCanvas::do_getPixels (this=<optimized out>, gh=...) at ../libgui/graphics/GLCanvas.cc:332
#10 0x00007f5fccf774f5 in octave::Canvas::getPixels (this=<optimized out>) at ../libgui/graphics/Canvas.h:83
#11 0x00007f5fccf5bfa6 in octave::Figure::slotGetPixels (this=<optimized out>) at ../libgui/graphics/Figure.cc:341
#12 0x00007f5fcd012406 in octave::Figure::qt_static_metacall (_o=<optimized out>, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7f5eacbf1e40) at libgui/graphics/moc-Figure.cc:117
#13 0x00007f5fcb150fec in QObject::event (this=<optimized out>, e=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qobject.cpp:1431
#14 0x00007f5fcc23d7af in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x2c630dc0, e=0x2e12a980) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/widgets/kernel/qapplication.cpp:3301
#15 0x00007f5fcd1daf52 in octave::octave_qapplication::notify (this=0x2ac2b440, receiver=<optimized out>, ev=<optimized out>) at ../libgui/src/octave-qobject.cc:153
#16 0x00007f5fcb0f5fa8 in QCoreApplication::notifyInternal2 (receiver=0x2c630dc0, event=0x2e12a980) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qcoreapplication.cpp:1106
#17 0x00007f5fcb0f620d in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qcoreapplication.cpp:1546
#18 0x00007f5fcb0f9cd6 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x2ac36c60) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qcoreapplication.cpp:1879
#19 0x00007f5fcb3ffd2f in postEventSourceDispatch (s=0x2b5b1490) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:246
#20 0x00007f5fc24fa040 in g_main_dispatch (context=0x2b5d0680) at ../glib/gmain.c:3398
#21 g_main_context_dispatch_unlocked (context=0x2b5d0680) at ../glib/gmain.c:4249
#22 0x00007f5fc2503128 in g_main_context_iterate_unlocked (context=context@entry=0x2b5d0680, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4314
#23 0x00007f5fc25032d3 in g_main_context_iteration (context=0x2b5d0680, may_block=1) at ../glib/gmain.c:4379
#24 0x00007f5fcb3ff56d in QEventDispatcherGlib::processEvents (this=0x2b5d5bd0, flags=...) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:399
#25 0x00007f5fcb103783 in QEventLoop::exec (this=this@entry=0x7ffef7b77290, flags=..., flags@entry=...) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/global/qflags.h:77
#26 0x00007f5fcb0ff229 in QCoreApplication::exec () at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/kernel/qcoreapplication.cpp:1449
#27 0x00007f5fcd1e2121 in octave::base_qobject::exec (this=0x7ffef7b77330) at ../libgui/src/octave-qobject.cc:438
#28 0x00007f5fcd20edf5 in octave::qt_application::execute (this=0x7ffef7b77508) at ../libgui/src/qt-application.cc:104
#29 0x000000000042f22a in main (argc=10, argv=0x7ffef7b77878) at ../src/main-gui.cc:168


Dmitri.
--



(file #57235)

Dmitri A. Sergatskov <dasergatskov>
Thu 22 May 2025 02:29:53 PM UTC, comment #12: 

I did "xvfb-run -s '-screen 0 640x480x8' octave" on run-level 3, and I got a coredump during "test getframe".

(Test passed with the default 640x480x24 setting)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 22 May 2025 01:35:42 PM UTC, comment #11: 

comment #8:

> Or it could be one of the hardening flags that you are using which is exposing this.
>


Tested with -D_FORTIFY_SOURCE=2 (openSUSE defaults to 3, which can sometimes cause code segfaults), but the crash persists.

comment #10:

> Another complication is whether you have Wayland running or not.
> On Fedora 42 Wayland is default an "xvfb-run" does not seem to be  working correctly. If I do:


> $ DISPLAY="" xvfb-run ./run-octave
> octave:1> plot (1:3)


> it pops a plot window on my screen (it should not).
> ("xwvb-run" seems to work correctly though)
>


I do not have a clear idea of how/what flags xvfb-run sets at startup. openSUSE does default to wayland for displays, but I see that xvfb-run does not set the WAYLAND_DISPLAY env variable that would confirm that wayland is indeed in use. It does set plain old DISPLAY, however.

In any case, on my proper machine, with GNOME on Wayland running, the tests all run fine. This is likely because the colour bit depth is more than 8. The crash is oddly specific to bit-depth of 8, which is used by xvfb-run by default on openSUSE but is not the bit depth on any real machine I imagine.

Thanks for the comments.

Atri Bhattacharya <badshah400>
Wed 21 May 2025 12:25:59 PM UTC, comment #10: 

Another complication is whether you have Wayland running or not.
On Fedora 42 Wayland is default an "xvfb-run" does not seem to be  working correctly. If I do:

$ DISPLAY="" xvfb-run ./run-octave
octave:1> plot (1:3)

it pops a plot window on my screen (it should not).
("xwvb-run" seems to work correctly though)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 21 May 2025 07:51:05 AM UTC, comment #9: 

Oops. I was looking at the documentation for the wrong version of Ubuntu.
For Ubuntu 24.04 (which is used by the GitHub-hosted runners), the default size and depth are 1280x1024x24:
https://manpages.ubuntu.com/manpages/noble/man1/Xvfb.1.html

So, that's probably not the cause for the warnings(?) from libunwind.

Markus Mützel <mmuetzel>
Group administrator
Wed 21 May 2025 07:46:09 AM UTC, comment #8: 

Interesting find.

Apparently, we are running the tests with these arguments on our buildbots (on Debian):

 argv: [b'nice', b'-n', b'19', b'xvfb-run', b'-a', b'-s', b'-screen 0 640x480x24', b'make', b'V=1', b'check']


According to Ubuntu's documentation, the default virtual display size and depth are 1280x1024x8. [1]

We aren't overriding that default on our CI on GitHub (using Ubuntu). But it still passes that test. E.g.:
https://github.com/gnu-octave/octave/actions/runs/15142927320/job/42571875029#step:13:496

  image/getframe.m ............................................... pass    2/2    [ 0.213s /  0.205s]


There might be something fishy going on there though. At least, the output from that test is more verbose on the GitHub-CI if Octave was built with LLVM Clang and it is linking with LLVM libc++ (instead of GNU libstdc++). E.g.:
https://github.com/gnu-octave/octave/actions/runs/15142927320/job/42571875016#step:13:502

  image/getframe.m ...............................................libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
 pass    2/2    [ 0.314s /  0.345s]


I'll try if overriding the default screen depth makes a difference for the CI runners.

All of this might also depend on how Qt6 was built? As far as I can tell, get_frame eventually uses a QOpenGLFramebufferObject [2] to get the pixel data while using the "qt" graphics_toolkit (which is the default for Octave if it was built with Qt).
Eventually, we are reading (unsigned) 8-bit integers from the OpenGL buffer. So, I don't know why the default screen depth of 8 doesn't suffice.

Or it could be one of the hardening flags that you are using which is exposing this.

I'm still not sure if there is anything that Octave can do about this.

[1]: https://manpages.ubuntu.com/manpages/trusty/man1/Xvfb.1.html
[2]: https://doc.qt.io/qt-6/qopenglframebufferobject.html

Markus Mützel <mmuetzel>
Group administrator
Wed 21 May 2025 06:47:58 AM UTC, comment #7: 

After quite a bit of hit and trial, it looks like that specific test (image/getframe.m) requires (at least) a colour depth of 16bits to run ok. xvfb-run uses a 640x480x8 screen configuration by default, and the test seg faults as reported here. However, I changed the screen config to 640x480x16 (using xvfb-run -s "-screen 0 640x480x16") and all tests, including the getframe one, succeeded.

Note that Fedora uses a full xorg.conf based setup for their build environment to run the tests, which sets the screen depth to 24 (and make-check, therefore, succeeds).

So, if someone could confirm this bit-depth requirement for the tests, I would greatly appreciate that.

>  I still think this is likely due to no working DISPLAY while running `make check` in your build setup.


xvfb-run sets up the display and exports the DISPLAY env var, so that should not be a problem. Indeed, other GUI tests run ok, except the image/getframe.m test, which as reported seg faults on 8bit depth screen setups.

> On my machine (Fedora 42) it passes when is run under xvfb-run


What colour depth does xvfb-run set for 'screen 0' by default on Fedora?

Thanks for all your responses.

Atri Bhattacharya <badshah400>
Mon 12 May 2025 02:39:08 PM UTC, comment #6: 

On my machine (Fedora 42) it passes when is run under xvfb-run,
If I unset DISPLAY, it skips the tests.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 12 May 2025 02:24:15 PM UTC, comment #5: 

See comment #1:

> Is xvfb correctly configured? Does Mesa work correctly on the runners that are used for that test?


I still think this is likely due to no working DISPLAY while running `make check` in your build setup.

I don't know which change Rik was referring to (because there likely is nothing Octave can do about that if it really is caused by an issue in the configuration of your build setup).

Markus Mützel <mmuetzel>
Group administrator
Mon 12 May 2025 02:00:36 PM UTC, comment #4: 

comment #3:

>
> This particular bug has already been fixed in a newer version of
> Octave. You may want to check for a software upgrade.
>


Does not look like it has, as of version 10.1.0:


[  596s]   image/getframe.m ...............................................fatal: caught signal Segmentation fault -- stopping myself...
[  596s] /usr/bin/bash: line 1: 121028 Segmentation fault      ( /usr/bin/bash ../run-octave --no-init-file --quiet --no-history -p /home/abuild/rpmbuild/BUILD/octave-10.1.0-build/octave-10.1.0/test/mex /home/abuild/rpmbuild/BUILD/octave-10.1.0-build/octave-10.1.0/test/fntests.m /home/abuild/rpmbuild/BUILD/octave-10.1.0-build/octave-10.1.0/test "" )


The make check RUN_OCTAVE_OPTIONS="--no-gui-libs" work-around still works, thankfully.

Atri Bhattacharya <badshah400>
Tue 26 Nov 2024 12:54:43 AM UTC, comment #3: 

Thanks for taking the time to report this bug.

This particular bug has already been fixed in a newer version of
Octave. You may want to check for a software upgrade.

Rik <rik5>
Group administrator
Mon 10 Jun 2024 12:57:12 PM UTC, comment #2: 

Many thanks for the quick response.

comment #1:

> Thank you for the report.
>
> There is a known compatibility issue with Qt6 6.7.x in Octave 9.1.0. But that should have been addressed by the changes for Octave 9.2.0.
>
> ISTR that we have seen on other platforms (Windows iirc) that some headless runners have issues with that particular test.
> ISTR, that running the test suite with `make check RUN_OCTAVE_OPTIONS="--no-gui-libs"` worked around that issue.
> Using that flag means that `octave-cli` (instead of `octave-gui`) will be used for the test suite. That executable doesn't link to libgui (that is used for the OpenGL graphics toolkits among other things). That also means that the tests for getframe.m (and some other files) will be skipped.
>


Just tested that this works. So, indeed, this might be an issue with how xvfb-run is working inside the build system chroot. Weird thing is that the other GUI tests work, and our previously packaged version 8.4.0 also had the full test-suite running without any issue.

>
> Is xvfb correctly configured? Does Mesa work correctly on the runners that are used for that test?
>


I am going to test this more rigorously and try to figure out what is going on but, in the meantime, the "no-gui-libs" workaround should be just fine.

> If you opt in to the workaround with `--no-gui-libs`, please test manually that `test getframe` doesn't crash Octave on a local installation (with head). After all, that could be an issue in the GUI libraries that is not only triggered on headless systems.


Tested this, and it works:


~> octave --version
GNU Octave, version 9.2.0
Copyright (C) 1993-2024 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

Octave was configured for "x86_64-suse-linux-gnu".

Home page:            https://octave.org
Support resources:    https://octave.org/support
Improve Octave:       https://octave.org/get-involved

~> octave --eval "test getframe"
PASSES 2 out of 2 tests


Thanks again for the help.

Atri Bhattacharya <badshah400>
Mon 10 Jun 2024 10:41:56 AM UTC, comment #1: 

Thank you for the report.

There is a known compatibility issue with Qt6 6.7.x in Octave 9.1.0. But that should have been addressed by the changes for Octave 9.2.0.

ISTR that we have seen on other platforms (Windows iirc) that some headless runners have issues with that particular test.
ISTR, that running the test suite with `make check RUN_OCTAVE_OPTIONS="--no-gui-libs"` worked around that issue.
Using that flag means that `octave-cli` (instead of `octave-gui`) will be used for the test suite. That executable doesn't link to libgui (that is used for the OpenGL graphics toolkits among other things). That also means that the tests for getframe.m (and some other files) will be skipped.

I'm seeing the following prior output in the test log which could be related:

[ 1056s]   libinterp/corefcn/gh-manager.cc-tst ............................MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
[ 1056s] libEGL warning: egl: failed to create dri2 screen
[ 1056s] libEGL warning: DRI2: failed to create any config
[ 1056s] MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
[ 1056s] libEGL warning: egl: failed to create dri2 screen
[ 1056s] libEGL warning: DRI2: failed to create any config
[ 1056s]  pass    1/1    [ 0.087s /  0.086s]


Is xvfb correctly configured? Does Mesa work correctly on the runners that are used for that test?

If you opt in to the workaround with `--no-gui-libs`, please test manually that `test getframe` doesn't crash Octave on a local installation (with head). After all, that could be an issue in the GUI libraries that is not only triggered on headless systems.

Does it make a difference if you run the test suite with that flag?

If it still crashes, would it be possible to get a backtrace from that crash?
If you can build Octave locally and reproduce the crash there, it should be possible to attach a debugger to Octave by starting it with `./run-octave -g --gui` in the build tree.

Markus Mützel <mmuetzel>
Group administrator
Mon 10 Jun 2024 09:52:47 AM UTC, original submission:  

Hi,
While trying to build a RPM package for openSUSE Tumbleweed, we run make check to ensure the test-suite succeeds. However, with version 9.2.0, we find that the test-suite encounters a segfault that leads to the test-suite failing. The relevant snippet from the full build log (attached) is as follows:


[ 1129s]   image/getframe.m ...............................................fatal: caught signal Segmentation fault -- stopping myself...
[ 1129s] /usr/bin/bash: line 1: 29829 Segmentation fault      ( /usr/bin/bash ../run-octave --no-init-file --silent --no-history -p /home/abuild/rpmbuild/BUILD/octave-9.2.0/t
est/mex /home/abuild/rpmbuild/BUILD/octave-9.2.0/test/fntests.m /home/abuild/rpmbuild/BUILD/octave-9.2.0/test "" )
[ 1129s] make[4]: *** [Makefile:3202: check-local] Error 139
[ 1129s] make[4]: Leaving directory '/home/abuild/rpmbuild/BUILD/octave-9.2.0/test'
[ 1129s] make[3]: *** [Makefile:3050: check-am] Error 2
[ 1129s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/octave-9.2.0/test'
[ 1129s] make[2]: *** [Makefile:3052: check] Error 2
[ 1129s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/octave-9.2.0/test'
[ 1129s] make[1]: *** [Makefile:28220: check-recursive] Error 1
[ 1129s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/octave-9.2.0'
[ 1129s] make: *** [Makefile:28518: check] Error 2


Thanks in advance for any suggestions to fix/work around this.




Here are some package versions that may help in diagnosing the issue:

  • GCC 13.3
  • Qt 6.7.1
  • java-21-openjdk 21.0.3


The following is the status after running configure:


[  117s] Octave is now configured for x86_64-suse-linux-gnu
[  117s]
[  117s]   Source directory:              .
[  117s]   Installation prefix:           /usr
[  117s]   C compiler:                    gcc  -pthread -fopenmp -fexceptions  -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g
[  117s]   C++ compiler:                  g++  -pthread -fopenmp  -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g
[  117s]   Fortran compiler:              gfortran -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g  -std=legacy -fexceptions
[  117s]   CPPFLAGS:
[  117s]   Fortran libraries:              -L/usr/lib64/gcc/x86_64-suse-linux/13 -L/usr/lib64/gcc/x86_64-suse-linux/13/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/13/../../.. -lgfortran -lm -lquadmath
[  117s]   Lex libraries:
[  117s]   LIBS:                          -lpthread -lm
[  117s]   LDFLAGS:                       -flto=auto
[  117s]   Extra LDFLAGS:
[  117s]
[  117s]   AMD CPPFLAGS:                  -I/usr/include/suitesparse
[  117s]   AMD LDFLAGS:
[  117s]   AMD libraries:                 -lamd
[  117s]   ARPACK CPPFLAGS:               -I/usr/include/arpack
[  117s]   ARPACK LDFLAGS:
[  117s]   ARPACK libraries:              -larpack
[  117s]   BLAS libraries:                -lopenblas
[  117s]   BZ2 CPPFLAGS:
[  117s]   BZ2 LDFLAGS:
[  117s]   BZ2 libraries:                 -lbz2
[  117s]   CAMD CPPFLAGS:                 -I/usr/include/suitesparse
[  117s]   CAMD LDFLAGS:
[  117s]   CAMD libraries:                -lcamd
[  117s]   CARBON libraries:
[  117s]   CCOLAMD CPPFLAGS:              -I/usr/include/suitesparse
[  117s]   CCOLAMD LDFLAGS:
[  117s]   CCOLAMD libraries:             -lccolamd
[  117s]   CHOLMOD CPPFLAGS:              -I/usr/include/suitesparse
[  117s]   CHOLMOD LDFLAGS:
[  117s]   CHOLMOD libraries:             -lcholmod
[  117s]   COLAMD CPPFLAGS:               -I/usr/include/suitesparse
[  117s]   COLAMD LDFLAGS:
[  117s]   COLAMD libraries:              -lcolamd
[  117s]   CURL CPPFLAGS:
[  117s]   CURL LDFLAGS:
[  117s]   CURL libraries:                -lcurl
[  117s]   CXSPARSE CPPFLAGS:             -I/usr/include/suitesparse
[  117s]   CXSPARSE LDFLAGS:
[  117s]   CXSPARSE libraries:            -lcxsparse
[  117s]   DL libraries:
[  117s]   FFTW3 CPPFLAGS:
[  117s]   FFTW3 LDFLAGS:
[  117s]   FFTW3 libraries:               -lfftw3_threads -lfftw3
[  117s]   FFTW3F CPPFLAGS:
[  117s]   FFTW3F LDFLAGS:
[  117s]   FFTW3F libraries:              -lfftw3f_threads -lfftw3f
[  117s]   FLTK CPPFLAGS:
[  117s]   FLTK LDFLAGS:                  -flto=auto
[  117s]   FLTK libraries:                -lfltk_gl -lfltk
[  117s]   fontconfig CPPFLAGS:           -I/usr/include/freetype2
[  117s]   fontconfig libraries:          -lfontconfig -lfreetype
[  117s]   FreeType2 CPPFLAGS:            -I/usr/include/freetype2
[  117s]   FreeType2 libraries:           -lfreetype
[  117s]   GLPK CPPFLAGS:
[  117s]   GLPK LDFLAGS:
[  117s]   GLPK libraries:                -lglpk
[  117s]   HDF5 CPPFLAGS:
[  117s]   HDF5 LDFLAGS:
[  117s]   HDF5 libraries:                -lhdf5
[  117s]   Java home:                     /usr/lib64/jvm/java-21-openjdk-21
[  117s]   Java JVM path:                 /usr/lib64/jvm/java-21-openjdk-21/lib/server
[  117s]   Java CPPFLAGS:                 -I/usr/lib64/jvm/java-21-openjdk-21/include -I/usr/lib64/jvm/java-21-openjdk-21/include/linux
[  117s]   Java libraries:
[  117s]   KLU CPPFLAGS:                  -I/usr/include/suitesparse
[  117s]   KLU LDFLAGS:
[  117s]   KLU libraries:                 -lklu
[  117s]   LAPACK libraries:
[  117s]   Magick++ CPPFLAGS:             -I/usr/include/GraphicsMagick
[  117s]   Magick++ LDFLAGS:
[  117s]   Magick++ libraries:            -lGraphicsMagick++ -lGraphicsMagick
[  117s]   OpenGL libraries:              -lGL -lGLU
[  117s]   PCRE CPPFLAGS:
[  117s]   PCRE LDFLAGS:
[  117s]   PCRE libraries:                -lpcre2-8
[  117s]   PortAudio CPPFLAGS:
[  117s]   PortAudio LDFLAGS:
[  117s]   PortAudio libraries:           -lportaudio -lm -lpthread -lasound
[  117s]   PTHREAD flags:                 -pthread
[  117s]   PTHREAD libraries:             -lpthread
[  117s]   QHULL CPPFLAGS:
[  117s]   QHULL LDFLAGS:
[  117s]   QHULL libraries:               -lqhull_r
[  117s]   QRUPDATE CPPFLAGS:
[  117s]   QRUPDATE LDFLAGS:
[  117s]   QRUPDATE libraries:            -lqrupdate
[  117s]   Qt CPPFLAGS:                   -I/usr/include/qt6/QtHelp -I/usr/include/qt6 -I/usr/include/qt6/QtGui -I/usr/include/qt6/QtSql -I/usr/include/qt6/QtNetwork -I/usr/include/qt6/QtOpenGL -I/usr/include/qt6/QtOpenGLWidgets -I/usr/include/qt6/QtPrintSupport -I/usr/include/qt6/QtWidgets -I/usr/include/qt6/QtXml -I/usr/include/qt6/QtCore5Compat -I/usr/include/qt6/QtCore -I/usr/lib64/qt6/mkspecs/linux-g++
[  117s]   Qt LDFLAGS:
[  117s]   Qt GUI libraries:              -lQt6Help -lQt6Gui -lQt6Sql -lQt6Network -lQt6OpenGL -lQt6OpenGLWidgets -lQt6PrintSupport -lQt6Widgets -lQt6Xml -lQt6Core5Compat -lQt6Core -lqscintilla2_qt6
[  117s]   Qt moc:                        /usr/libexec/qt6/moc
[  117s]   Qt uic:                        /usr/libexec/qt6/uic
[  117s]   Qt rcc:                        /usr/libexec/qt6/rcc
[  117s]   Qt lrelease:                   /usr/lib64/qt6/bin/lrelease
[  117s]   Qt qcollectiongenerator:       /usr/libexec/qt6/qhelpgenerator
[  117s]   Qt qhelpgenerator:             /usr/libexec/qt6/qhelpgenerator
[  117s]   READLINE libraries:            /usr/lib64/libreadline.so
[  117s]   Sndfile CPPFLAGS:              -I/usr/include/opus
[  117s]   Sndfile LDFLAGS:
[  117s]   Sndfile libraries:             -lsndfile
[  117s]   SPQR CPPFLAGS:                 -I/usr/include/suitesparse
[  117s]   SPQR LDFLAGS:
[  117s]   SPQR libraries:                -lspqr
[  117s]   SuiteSparse config libraries:  -lsuitesparseconfig
[  117s]   SUNDIALS core CPPFLAGS:
[  117s]   SUNDIALS core LDFLAGS:
[  117s]   SUNDIALS core libraries:       -lsundials_core
[  117s]   SUNDIALS IDA CPPFLAGS:
[  117s]   SUNDIALS IDA LDFLAGS:
[  117s]   SUNDIALS IDA libraries:        -lsundials_ida
[  117s]   SUNDIALS NVECTOR CPPFLAGS:
[  117s]   SUNDIALS NVECTOR LDFLAGS:
[  117s]   SUNDIALS NVECTOR libraries:    -lsundials_nvecserial
[  117s]   SUNLINSOL KLU CPPFLAGS:
[  117s]   SUNLINSOL KLU LDFLAGS:
[  117s]   SUNLINSOL KLU libraries:       -lsundials_sunlinsolklu
[  117s]   UMFPACK CPPFLAGS:              -I/usr/include/suitesparse
[  117s]   UMFPACK LDFLAGS:
[  117s]   UMFPACK libraries:             -lumfpack
[  117s]   X11 include flags:
[  117s]   X11 libraries:                 -lX11
[  117s]   Z CPPFLAGS:
[  117s]   Z LDFLAGS:
[  117s]   Z libraries:                   -lz
[  117s]
[  117s]   Default pager:                 less
[  117s]   gnuplot:                       gnuplot
[  117s]
[  117s]   Build Octave Qt GUI:                  yes (version: 6)
[  117s]   Build Java interface:                 yes
[  117s]   Build static libraries:               no
[  117s]   Build shared libraries:               yes
[  117s]   Dynamic Linking API:                  dlopen
[  117s]   Use library visibility flags:         no
[  117s]   64-bit array dims and indexing:       yes
[  117s]   64-bit BLAS array dims and indexing:  no
[  117s]   Use std::pmr::polymorphic_allocator:  no
[  117s]   OpenMP SMP multithreading:            yes
[  117s]   Truncate intermediate FP results:     yes
[  117s]   Include support for GNU readline:     yes
[  117s]   Use push parser in command line REPL: yes
[  117s]   Build cross tools:                    no
[  117s]   Build docs:                           no
[  117s]   Embed Mercurial ID in libraries:      yes
[  117s]   Install build logs:                   no
[  117s]
[  117s] configure: WARNING:
[  117s]
[  117s] I didn't find texi2dvi, but it's only a problem if you need to
[  117s] reconstruct the DVI version of the manual
[  117s]
[  117s] configure: WARNING:
[  117s]
[  117s] I didn't find icotool, but it's only a problem if you need to
[  117s] reconstruct octave-logo.ico, which is the case if you're building from
[  117s] VCS sources.
[  117s]
[  117s] configure: WARNING:
[  117s]
[  117s] I didn't find rsvg-convert, but it's only a problem if you need to
[  117s] reconstruct octave-logo-*.png, which is the case if you're building
[  117s] from VCS sources.
[  117s]
[  117s] configure: WARNING: building documentation disabled; make dist will fail.


Atri Bhattacharya <badshah400>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #57239:  getframe_fix1.diff added by dasergatskov (2KiB - text/x-patch)
file #57235:  coredump_getframe.txt.gz added by dasergatskov (6KiB - application/gzip)
file #56152:  build.log.gz added by badshah400 (200KiB - application/gzip - Full build log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by badshah400 (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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-06 mmuetzel StatusIn Progress Ready For Test
        Planned ReleaseNone 10.3.0 (current stable)
    2025-05-23 dasergatskov Attached File- Added getframe_fix1.diff, #57239
    2025-05-23 mmuetzel CategoryTest Suite Plotting with OpenGL
    2025-05-22 mmuetzel StatusFixed In Progress
        Open/ClosedClosed Open
        Operating SystemGNU/Linux Any
        Fixed Release9.2.0 None
        Planned Release9.2.0 None
    2025-05-22 dasergatskov Attached File- Added coredump_getframe.txt.gz, #57235
    2024-11-26 rik5 Open/ClosedOpen Closed
        Release9.2.0 9.1.0
        Fixed ReleaseNone 9.2.0
        Planned ReleaseNone 9.2.0
    2024-11-26 rik5 StatusNeed Info Fixed
    2024-06-10 mmuetzel StatusNone Need Info
    2024-06-10 badshah400 Attached File- Added build.log.gz, #56152

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code