Scilab does not start after some upgrades on Ubuntu Xenial
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mesa |
Won't Fix
|
High
|
|||
libjogl2-java (Ubuntu) |
Undecided
|
Timo Aaltonen | |||
Xenial |
Undecided
|
Unassigned | |||
Artful |
Undecided
|
Unassigned | |||
mesa (Ubuntu) |
Undecided
|
Unassigned | |||
Xenial |
Undecided
|
Unassigned | |||
Artful |
Undecided
|
Unassigned | |||
scilab (Debian) |
Fix Released
|
Unknown
|
|||
scilab (Ubuntu) |
Undecided
|
Unassigned | |||
Xenial |
Undecided
|
Unassigned | |||
Artful |
Undecided
|
Unassigned |
Bug Description
[Impact]
Software that use libjogl2-java (Scilab, Matlab,...) fail to run, because Mesa dropped 'Gallium' from the renderer string.
[Test case]
Steps to reproduce:
1. have installed Scilab on Ubuntu Xenial system
2. install system updates
3. try to launch Scilab from GUI - it does not start
4. try to launch Scilab from terminal - it does not start with the following output in the terminal:
$ scilab
Could not create a Scilab main class. Error:
Exception in thread "main" java.lang.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at java.security.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at org.scilab.
at org.scilab.
at org.scilab.
Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).
Expected results:
Scilab works normally on Ubuntu 16.04 LTS system.
Actual results:
see error above.
[Regression potential]
The fix is a simple oneliner that allows libjogl2-java to detect Mesa with both new and original version of Mesa.
Hi Sergio,
I won't be looking at the issue, I'm afraid yet here's a couple of ideas/suggestions that should help:
- try to track down the first Mesa version (ideally a commit) that breaks things
- isolate that the issue is not LLVM related by rebuilding mesa without it
- check that the correct libraries are picked (using strace or LD_DEBUG=libs)
Matlab might be shipping libraries (say libc/libstdc++) that are older than the ones Mesa is build against.
- try to get more verbose information of the issue - not sure if the dev. will have a matlab license to debug themselves
Hi,
I totally understand the difficulty in looking into an issue related to (expensive) commercial, that - as such - is hard to reproduce.
Thanks for the suggestion, even if - on a machine that is in use - I will not be able to do any bisection.
I'll try to work on the last point aka get more verbose information.
In any case, my intent was mostly to assure that a trace of the problem is present on the bug tracker, in case other users run into the issue and possibly to guide them if they need to get new hardware with the need to run Matlab on it.
Unfortunately the Matlab experience on Linux is sad. Not working with nouveau. Not working with soft rendering, either. Working with its own soft rendering, but with many limitations. Fortunately, it seems OK on intel graphics.
|
#43 |
Sergio, I installed the 30-day trial of Matlab r2017b and typed 'opengl info' in the command window. I did not get a java exception. I got an error message that reads:
"""
MATLAB has experienced a low-level graphics error, and may not have drawn correctly.
Read about what you can do to prevent this issue at Resolving Low-Level Graphics Issues then restart MATLAB.
To share details of this issue with MathWorks technical support,
please include this file with your service request.
"""
I don't see that issue when using NVIDIA's driver.
I used apitrace to create a trace of Matlab's GL calls with llvmpipe and with NVIDIA's linux driver. It looks like Matlab begins by trying to find the highest supported GL version of the core profile. With NVIDIA's driver it finds 4.5. With llvmpipe it finds 3.3.
Then, it also tries to create compatibility profile context. With NVIDIA's driver it again gets a 4.5 context. With llvmpipe, we don't have such profiles and Matlab stops after getting a GL 3.1 context.
Finally, with llvmpipe, Matlab tries to create a 3.3 compatibility profile and fails. It then successfully creates a legacy context with glXCreateNewCon
As far as I an tell, Matlab simply doesn't accept llvmpipe's context/version offerings. Either that's by design or there's some sort of logic bug in MatLab that gives up on GL support after failing to create a particular kind of context.
You could try installing some older versions of Mesa to see if Matlab 2016a works/fails. But Matlab 2017b seems to act differently.
@Brian
thanks for testing! Indeed, I think that Matlab 2016 is fine with the NVIDIA proprietary driver. However, I cannot use it because I have a KDE desktop and the nvidia proprietary drivers hang the konsole as per
https:/
https:/
Furthermore, I prefer the free drivers when my graphics card copes with them.
The different response to the opengl info may be related to a slightly different mesa/graphics stack combination. Incidentally, it is unclear to me whether you got the "MATLAB has experienced a low-level graphics error" with llvmpipe or the hardware driver.
Matlab seems to use some java library to interact with opengl and I do not know if it is something commercial or something open source that MathWorks has adapted to its needs. In the latter case, testing might be easier.
... looks like also scilab has issues with the software renderer. With LIBGL_ALWAYS_
Scilab gives
Exception in thread "AWT-EventQueue-0" javax.media.
at javax.media.
at javax.media.
at javax.media.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at java.security.
at java.security.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at javax.swing.
at java.awt.
at java.awt.
at java.awt.
at java.awt.
at java.awt.
at java.security.
at java.security.
at java.awt.
at java.awt.
at java.awt.
at java.awt.
at java.awt.
at java.awt.
at java.awt.
Caused by: javax.media.
Obviously, at least with scilab, there is an important regression.
Note that the scilab website itself, since the release of scilab 5.X (for the last 2-3 years) has advised to use LIBGL_ALWAYS_
https:/
scilab breaks starting with:
commit 92b4ca45504e7ff
Author: Marek Olšák <email address hidden>
Date: Wed Jun 7 22:00:48 2017 +0200
st/mesa: remove the "Gallium 0.4 on" prefix from GL_RENDERER
If you want to keep it for your driver, please raise your hand.
The prefix will probably have to be added into the driver instead of here.
I cringe when I look at my long renderer string:
Gallium 0.4 on AMD Radeon R9 Fury Series (DRM 3.17.0 / 4.11.0-
I'm sincerely sorry for all apps that detect Mesa by expecting "Gallium"
in the string.
Reviewed-by: Eric Anholt <email address hidden>
It seems jogl wants to detect mesa and alter its behavior based on that:
(In reply to Scott D Phillips from comment #8)
> It seems jogl wants to detect mesa and alter its behavior based on that:
>
> https:/
> 45cc13c4d68fb31
> GLContextImpl.
At a quick glance, my guess would be the issues are around GLRendererQuirk
It would then refuse to use such contexts.
(I would tend to think it is a bug in jogl somewhere with different gl versions being available for core/compat contexts but I have no idea really.)
Norbert (nrbrtx) wrote : | #1 |
Norbert (nrbrtx) wrote : | #2 |
According to scilab changelog it does not changed since
scilab (5.5.2-2ubuntu3) xenial; urgency=medium
* Enable debian/
since fop 2.0 is now in Ubuntu.
-- Graham Inggs <email address hidden> Wed, 06 Apr 2016 18:32:35 +0200
So it is graphics issue. Possible related to bug 1741447.
Norbert (nrbrtx) wrote : | #3 |
Installed `vainfo` and `mesa-va-drivers`
`sudo apt-get install mesa-va-drivers vainfo`
Here is my output of `vainfo`:
$ vainfo
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfile
VAProfileNone : VAEntrypointVid
$ lspci -knn | grep -A3 VGA
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:0123]
Kernel driver in use: radeon
Kernel modules: radeon
$ cat /proc/cmdline
BOOT_IMAGE=
$ glxinfo | grep -i 'direct\
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Vendor: X.Org (0x1002)
OpenGL vendor string: X.Org
OpenGL renderer string: AMD ARUBA (DRM 2.43.0 / 4.4.0-109-generic, LLVM 5.0.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 17.2.4
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
GL_
GL_
GL_
OpenGL version string: 3.0 Mesa 17.2.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
Norbert (nrbrtx) wrote : | #4 |
Upgrading to HWE does not help.
Timo Aaltonen (tjaalton) wrote : | #5 |
does it work on artful?
Timo Aaltonen (tjaalton) wrote : | #6 |
also, you could try ppa:canonical-
Timo Aaltonen (tjaalton) wrote : | #7 |
same bug on Debian, so probably doesn't work in artful either (nor bionic)
Changed in scilab (Debian): | |
status: | Unknown → New |
Norbert (nrbrtx) wrote : | #8 |
Asked question on AskUbuntu (https:/
Fixed by blacklisting `radeon`:
cat <<EOF | sudo tee /etc/modprobe.
# blacklist radeon module to allow run at least Scilab after Mesa upgrade
blacklist radeon
EOF
sudo update-initramfs -k all -u
Timo Aaltonen (tjaalton) wrote : | #9 |
that's a bad workaround if your gfx card is radeon..
Timo Aaltonen (tjaalton) wrote : | #10 |
from https:/
try adding LIBGL_ALWAYS_
Timo Aaltonen (tjaalton) wrote : | #11 |
this is actually a bug in jogl which seems to be doing stupid string checking to see if the driver is Mesa, and fails now that GL_RENDERER string doesn't have "Gallium" in it (wonder what happens with intel..)
Timo Aaltonen (tjaalton) wrote : | #12 |
actually that LIBGL_ALWAYS_
Changed in mesa: | |
importance: | Unknown → High |
status: | Unknown → Confirmed |
no longer affects: | scilab |
Norbert (nrbrtx) wrote : | #13 |
I saw this jogl bug (https:/
Potentially other programs are affected too (https:/
With newest Mesa Scilab works normally on i915 and nvidia_340 drivers.
Timo Aaltonen (tjaalton) wrote : | #14 |
yes I had a look at the code, it's just radeon and swrast which are busted because they no longer have "Gallium" in the renderer string
Changed in libjogl2-java (Ubuntu): | |
assignee: | nobody → Timo Aaltonen (tjaalton) |
status: | New → Triaged |
Norbert (nrbrtx) wrote : | #15 |
I do not know about Bionic, it maybe affected too.
I'll be watching this bug-report and re-enable `radeon` driver on my machine after fix.
Thank you for quick reaction, Timo!
Timo Aaltonen (tjaalton) wrote : | #16 |
Bionic should be affected, but I've pushed a fixed libjogl2-java to Debian now and it'll get synced later. Next will be SRU uploads to artful and xenial.
*** Bug 103976 has been marked as a duplicate of this bug. ***
*** Bug 103217 has been marked as a duplicate of this bug. ***
this is a bug in jogl, and apparently changing it to detect current Mesa makes it work again:
(In reply to Timo Aaltonen from comment #12)
> this is a bug in jogl, and apparently changing it to detect current Mesa
> makes it work again:
>
> https:/
They really should fix whatever it's doing wrong, rather than trying to avoid doing the wrong stuff when detecting a mesa-based driver... (I suspect it might be related to mesa not supporting compat profiles higher than 3.3 and jogl not handling this correctly, but really no idea. Doing hacks such as renderer detection might be ok as quick workarounds, but really the root cause should be fixed wherever it is.)
Changed in scilab (Debian): | |
status: | New → Fix Released |
Norbert (nrbrtx) wrote : | #17 |
My VESA solution is bad, I can't plot anything in Scilab even with LIBGL_ALWAYS_
SRU is really needed.
Norbert (nrbrtx) wrote : | #18 |
Downgraded the following packages:
libegl1-
libgbm1_
libgl1-
libgl1-
libgl1-
libgl1-
libglapi-
libglapi-
libgles2-
libosmesa6_
libosmesa6_
libwayland-
mesa-va-
mesa-vdpau-
And pinned them:
cat <<EOF | sudo tee /etc/apt/
Package: libegl1-mesa:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libgbm1:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libgl1-
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libgl1-
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libgl1-
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libgl1-
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libglapi-mesa:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libglapi-mesa:i386
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libgles2-mesa:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libosmesa6:amd64
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libosmesa6:i386
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: libwayland-
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: mesa-va-drivers
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
Package: mesa-vdpau-drivers
Pin: version 11.2.0-1ubuntu2
Pin-Priority: 1337
EOF
It is a temporarily fix, which works for me.
Norbert (nrbrtx) wrote : | #19 |
As we predicted, 17.10 (artful) is affected too - see this AskUbuntu question ( https:/
tags: | added: artful |
Launchpad Janitor (janitor) wrote : | #20 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in libjogl2-java (Ubuntu Artful): | |
status: | New → Confirmed |
Changed in libjogl2-java (Ubuntu Xenial): | |
status: | New → Confirmed |
Changed in mesa (Ubuntu Artful): | |
status: | New → Confirmed |
Changed in mesa (Ubuntu Xenial): | |
status: | New → Confirmed |
Changed in mesa (Ubuntu): | |
status: | New → Confirmed |
Changed in scilab (Ubuntu Artful): | |
status: | New → Confirmed |
Changed in scilab (Ubuntu Xenial): | |
status: | New → Confirmed |
Changed in scilab (Ubuntu): | |
status: | New → Confirmed |
Tim Wescott (ww3ib0-tim) wrote : | #28 |
Any news for the newbie on how soon the fix will be applied?
I see the comment on downgrading and pinning a bunch of MESA packages -- but I don't know exactly how to do the downgrade, nor how to safely undo the pinning once it's no longer necessary. I don't want to muck up my machine.
Changed in scilab (Ubuntu): | |
status: | Confirmed → Invalid |
Changed in scilab (Ubuntu Xenial): | |
status: | Confirmed → Invalid |
Changed in scilab (Ubuntu Artful): | |
status: | Confirmed → Invalid |
Changed in mesa (Ubuntu): | |
status: | Confirmed → Invalid |
Changed in mesa (Ubuntu Xenial): | |
status: | Confirmed → Invalid |
Changed in mesa (Ubuntu Artful): | |
status: | Confirmed → Invalid |
Hello Norbert, or anyone else affected,
Accepted libjogl2-java into artful-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
Changed in libjogl2-java (Ubuntu Artful): | |
status: | Confirmed → Fix Committed |
tags: | added: verification-needed verification-needed-artful |
description: | updated |
Łukasz Zemczak (sil2100) wrote : | #30 |
Hello Norbert, or anyone else affected,
Accepted libjogl2-java into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
Changed in libjogl2-java (Ubuntu Xenial): | |
status: | Confirmed → Fix Committed |
tags: | added: verification-needed-xenial |
Launchpad Janitor (janitor) wrote : | #31 |
This bug was fixed in the package libjogl2-java - 2.3.2+dfsg-7
---------------
libjogl2-java (2.3.2+dfsg-7) unstable; urgency=medium
* Reupload using correct .changes.
-- Timo Aaltonen <email address hidden> Sat, 13 Jan 2018 09:17:50 +0200
Changed in libjogl2-java (Ubuntu): | |
status: | Triaged → Fix Released |
Johan Marius Wesselink (johanmw) wrote : | #32 |
I tested the proposed package on Lubuntu 17.10.
I tested some example programs they use either:
GLProfile glp = GLProfile.
Or they use the GLCanvas default constructor.
Before this version all these examples emitted the typical error found in the previous version of jogl2. The new package RESOLVED this problem.
I noticed after some experimenting that replacing getDefault with get(GLProfile.GL2);
also solved the problem. Then I found this thread.
I build scilab from source using the git repository. This is the master and future 6.1 version it has the same problem. However, scilab 6 and higher have the jogl2 library prebuild and distributed as a thirdparty library. Removing this library doesn't work. The problem is that the scirender module and the gui modules depend on the old syntax. The Java path in the past was javax.media. In newer version of jogl2 this changed to com.jogamp. This means that besides removing the faulty library from scilab the modules scirender and gui need to be patched. I did just this in the last days. The git master branch version 6.1 build and works with the new jogl2 version. I noticed however one regression bug the cursor selection in the plot window work kind of inverted. This is an old bug which I have seen before.
So, yes this fixes the jogl2 bug. But, no likely not the scilab bug. Depends how you get scilab and which version probably.
Johan Marius Wesselink (johanmw) wrote : | #33 |
Tested the scilab 5.5.2 for ubuntu which works great.
However, I did not test it before applying the jogl2 patch :-o.
Had a look at the source and it seems that the Ubuntu version is patched to use the
generic version of jogl2.
I would like to try and get this patch integrated in the Scilab source tree.
Probably a difficult and slow process.
Timo Aaltonen (tjaalton) wrote : | #34 |
sounds like artful is verified, same for xenial would be great
tags: |
added: verification-done-artful removed: verification-needed-artful |
Launchpad Janitor (janitor) wrote : | #35 |
This bug was fixed in the package libjogl2-java - 2.3.2+dfsg-
---------------
libjogl2-java (2.3.2+
* fix-mesa-
-- Timo Aaltonen <email address hidden> Fri, 12 Jan 2018 21:23:23 +0200
Changed in libjogl2-java (Ubuntu Artful): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for libjogl2-java has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Dima (dima2017) wrote : | #37 |
Scilab works on xenial with the proposed update (libjogl2-java - 2.3.2+dfsg-
tags: |
added: verification-done-xenial removed: verification-needed-xenial |
Launchpad Janitor (janitor) wrote : | #38 |
This bug was fixed in the package libjogl2-java - 2.3.2+dfsg-
---------------
libjogl2-java (2.3.2+
* fix-mesa-
-- Timo Aaltonen <email address hidden> Fri, 12 Jan 2018 21:23:23 +0200
Changed in libjogl2-java (Ubuntu Xenial): | |
status: | Fix Committed → Fix Released |
fabcap77 (fabcap77) wrote : | #39 |
I observed the same problem also with Scilab under Ubuntu 14.04, with the following version of libjogl2-java:
libjogl2-
libjogl2-
Is there a fix available for Ubuntu Trusty?
*** Bug 105847 has been marked as a duplicate of this bug. ***
It sounds like this was actually a jogl bug, thus not our bug. Please re-open if I've misunderstood.
Changed in mesa: | |
status: | Confirmed → Won't Fix |
Software rendering with recent mesa (either LLVMPipe, softpipe or swr) breaks matlab.
Seen with MATLAB 2016a on Kubuntu 17.04 with the latest (git) mesa as of today.
Graphic commands (e.g. plot) hang and make it impossible to close Matlab cleanly.
On llvmpipe the 'opengl info' matlab command crashes with
Error using hgopengl RuntimeExceptio n: Waited 5000ms for: <38d5ebf2, 64757a04>[count 2 [ add. 0, orig 2], qsz 0, owner SharedResourceR unner] - <main> common. util.locks. RecursiveLockIm pl01Unfairish. lock(RecursiveL ockImpl01Unfair ish.java: 198) opengl. GLProfile. initSingleton( GLProfile. java:199) opengl. GLProfile. getDefaultDevic e(GLProfile. java:2003) opengl. GLCapabilities. <init>( GLCapabilities. java:84) hg.uij. OpenGLUtils$ MyGLListener. getGLInformatio n(OpenGLUtils. java:320) hg.uij. OpenGLUtils$ MyGLListener. getGLData( OpenGLUtils. java:498) hg.uij. OpenGLUtils. getGLData( OpenGLUtils. java:78)
Java exception occurred:
java.lang.
<Startup Class Loader>, add.owner Startup Class Loader-
at jogamp.
at com.jogamp.
at com.jogamp.
at com.jogamp.
at com.mathworks.
at com.mathworks.
at com.mathworks.
Error in hgopengl
On softpipe, the same command hangs.
This is curious because matlab has itself a software rendering mode, that seems to rely on mesa X11. The opengl info for it returns
SupportsDep
So, it looks like mesa was supporting matlab 2016a just fine at the time of 10.5.2 and that we are now facing a regression.