bugGNU Octave - Bugs: bug #53153, MXE octave crash after...

 
 

bug #53153: MXE octave crash after introduction of QOpenGLWidget

Submitter:  Rik <rik5>
Submitted:  Wed 14 Feb 2018 04:01:03 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 19 Jan 2019 05:52:23 PM UTC, comment #15: 

Closing report.

Rik <rik5>
Group administrator
Sat 19 Jan 2019 04:54:50 PM UTC, comment #14: 

Octave no longer starts on Windows XP.
Can we close this report as WON'T FIX?

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Feb 2018 05:41:24 PM UTC, comment #13: 

This issue is still present for me.  I have verified that --disable-system-opengl can be used as a workaround.  But, the long term solution is probably to choose the correct libGl at installation or runtime.  I've changed the category of the bug to "Configuration and Build System".

Rik <rik5>
Group administrator
Mon 19 Feb 2018 11:43:24 PM UTC, comment #12: 

I don't have a bin/libGL.dll.  I do have these


./bin/opengl32.dll
./bin/Qt5OpenGL.dll
./bin/Qt5OpenGLd.dll


Is one of those the correct one to move aside to verify that --disable-system-opengl definitely works?

I tried moving opengl32.dll but then Octave just won't start--it complains about an invalid entry point.

Rik <rik5>
Group administrator
Sun 18 Feb 2018 09:27:00 PM UTC, comment #11: 

Didn't read it carefully but this article may be useful:

https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/

Basically, the opengl library which is used by an application can be chosen and loaded dynamically at startup, based on feature tests.


Pantxo Diribarne <pantxo>
Group Member
Sun 18 Feb 2018 05:55:36 PM UTC, comment #10: 

Now that you have the binary built with the mesa libGL, you should be able to switch back to the system library by moving bin/libGL.dll aside.  If you try that, then Octave should still run and show you the same problem you had originally.

If that works as I expect, then maybe we should build libGL by default.  Then the choice of whether to use it could be made when Octave is installed.  Or possibly even when running Octave by putting libGL in a separate directory and then having the octave.vbs wrapper script add that directory to the PATH (on Windwos, I believe that makes a DLL available) before launching the actual Octave binary.

John W. Eaton <jwe>
Group administrator
Sun 18 Feb 2018 06:12:37 AM UTC, comment #9: 

Yes, the option --disable-system-opengl works for me, but how would someone downloading an Octave installer know to get the version that was comppiled with SW rendering versus the regular one?

Rik <rik5>
Group administrator
Fri 16 Feb 2018 09:13:35 PM UTC, comment #8: 

This is qt5, 32-bit system.  I'll try rebuilding with --disable-system-opengl.

Rik <rik5>
Group administrator
Fri 16 Feb 2018 06:30:42 AM UTC, comment #7: 

Is this with qt4 or qt5?

I don't see this issue with my build on a Windows 10 system installed directly on hardware or a Windows 7 system running in a VM.

Are you using the OpenGL libraries provided by your Windows installation and possibly hardware drivers?

Could you build with --disable-system-opengl?  I think that should enable mesa and give you a libGL that will do software rendering using the "softpipe" driver.  Does that avoid the crash?

John W. Eaton <jwe>
Group administrator
Fri 16 Feb 2018 12:26:04 AM UTC, comment #6: 

The changeset that introduced the crash is


changeset:   24142:59cdf06c940e
user:        John W. Eaton <jwe@octave.org>
date:        Fri Oct 13 13:22:09 2017 -0400
summary:     use QOpenGLWidget if it is available


Just guessing, but there may be some additional initialization that QOpenGLWidget requires that we are not doing.

Rik <rik5>
Group administrator
Thu 15 Feb 2018 12:35:22 AM UTC, comment #5: 

I've established that the plotting issue appeared between 8/31/17 and 11/17/17.  I'm going to concentrate on bisecting that window for this bug report.

However, along the way I found that the truncated initial message in the Command Window was introduced in the window from 11/17/17 to 1/1/18.  That might be helpful to you (jwe).

Rik <rik5>
Group administrator
Wed 14 Feb 2018 11:01:49 PM UTC, comment #4: 

It's tedious, but I used hg to go back to 8/31/17 and this cset


changeset:   23980:eb6602171d59
user:        Mike Miller <mtmiller@octave.org>
date:        Thu Aug 31 11:36:36 2017 -0700
summary:     configure: make SUNDIALS double precision test cross-compile-safe (bug #51904)


I then built dist-gzip, transferred the gzip file over to MXE and built that.  Finally I tested that version in the same Windows XP virtual machine.

The good news is that plotting works AND the initial message in the Command Window is not truncated.  Ergo, there must have been changes in the last 5.5 months that caused these regressions.  The bad news is that the compile/test cycle is very long and bisection could take a few days to locate the problem cset.


Rik <rik5>
Group administrator
Wed 14 Feb 2018 05:39:45 AM UTC, comment #3: 

32-bit installer.  The configure line for MXE is


./configure --disable-jit --disable-java --enable-qt5 --disable-windows-64 --enable-octave=default



Rik <rik5>
Group administrator
Wed 14 Feb 2018 05:08:46 AM UTC, comment #2: 

I tried the 32-bit installer generated by the buildbot on a Windows 7 system running in a VM and sombrero worked for me.  Just to be sure, I tried plot (1:10) and it also worked.  I can try a 64-bit build once one of the builds finishes.

John W. Eaton <jwe>
Group administrator
Wed 14 Feb 2018 04:56:05 AM UTC, comment #1: 

Which configuration?  32-bit Windows, 64-bit Windows with the default 32-bit Fortran integers, or 64-bit Windows with 64-bit Fortran integers?

John W. Eaton <jwe>
Group administrator
Wed 14 Feb 2018 04:01:03 AM UTC, original submission:  

Running on a Windows XP VM and self-compiled MXE Octave


octave_config_info ('hg_id')
ans = 6114be517240


Running


plot (1:10)


causes a crash.

However, when using FLTK as the toolkit there is no problem.



Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-19 rik5 StatusConfirmed Wont Fix
        Open/ClosedOpen Closed
    2018-02-28 rik5 CategoryOctave Function Configuration and Build System
    2018-02-16 rik5 SummaryMXE octave crash with any plot MXE octave crash after introduction of QOpenGLWidget
    2018-02-14 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code