Bug#926180: scilab: FTBFS on all - New trouble
On Tue, 14 May 2019 00:39:07 +0200 Alexis Murzeau wrote: > Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit : > > > > On 12/05/2019 22:10, Julien Puydt wrote: > >> Hi, > >> > >> On 12/05/2019 11:46, Alexis Murzeau wrote: > >> > >>> I saw that there is a bugfix release 6.0.2 with many fixes [0]. > >> I had started to package 6.0.2 on salsa already in february. I removed > >> the patch about Linenum as that was supposed to have been reworked and > >> fixed, and it now fails with : > >> > >> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I > >> ./src/xml2modelica nums.cmxa ./src/xml2modelica/xMLTree.ml > >> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml > >> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml > >> ./src/xml2modelica/xMLLexer.ml > >> ./src/xml2modelica/modelicaCodeGenerator.ml > >> ./src/xml2modelica/xML2Modelica.ml > >> File "./src/xml2modelica/xML2Modelica.ml", line 1: > >> Error: Files ./src/xml2modelica/xMLParser.cmx > >>and ./src/xml2modelica/linenum.cmx > >>make inconsistent assumptions over implementation Linenum > >> > >> ie : it looks like upstream's fix isn't correct. > > > > + upstream > > > > S > > > > > > Reversing the order of the includes parameters when compiling > XML2Modelica fix the build for me, ie. including xml2modelica first: > `-I ./src/xml2modelica -I ./src/modelica_compiler` > > I think ocamlopt prefer to use a part of Linenum from > ./src/modelica_compiler and the other one from ./src/xml2modelica which > lead to the error. > > But I'm not sure this is the way to handle it cleanly. > The files "linenum.mll" are almost the same between both directories. > The only difference is the comment at the beginning of the file. > > Maybe some of these "linenum.mll" file can be removed to keep only one ? Ubuntu has packaged 6.0.2 for Disco and Eoan, please see https://launchpad.net/ubuntu/+source/scilab or fetch the DSC directly from https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/scilab/6.0.2-0ubuntu2/scilab_6.0.2-0ubuntu2.dsc > > -- > Alexis Murzeau > PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F > >
Bug#926180: scilab: FTBFS on all - New trouble
Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit : > > On 12/05/2019 22:10, Julien Puydt wrote: >> Hi, >> >> On 12/05/2019 11:46, Alexis Murzeau wrote: >> >>> I saw that there is a bugfix release 6.0.2 with many fixes [0]. >> I had started to package 6.0.2 on salsa already in february. I removed >> the patch about Linenum as that was supposed to have been reworked and >> fixed, and it now fails with : >> >> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I >> ./src/xml2modelica nums.cmxa ./src/xml2modelica/xMLTree.ml >> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml >> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml >> ./src/xml2modelica/xMLLexer.ml >> ./src/xml2modelica/modelicaCodeGenerator.ml >> ./src/xml2modelica/xML2Modelica.ml >> File "./src/xml2modelica/xML2Modelica.ml", line 1: >> Error: Files ./src/xml2modelica/xMLParser.cmx >>and ./src/xml2modelica/linenum.cmx >>make inconsistent assumptions over implementation Linenum >> >> ie : it looks like upstream's fix isn't correct. > > + upstream > > S > > Reversing the order of the includes parameters when compiling XML2Modelica fix the build for me, ie. including xml2modelica first: `-I ./src/xml2modelica -I ./src/modelica_compiler` I think ocamlopt prefer to use a part of Linenum from ./src/modelica_compiler and the other one from ./src/xml2modelica which lead to the error. But I'm not sure this is the way to handle it cleanly. The files "linenum.mll" are almost the same between both directories. The only difference is the comment at the beginning of the file. Maybe some of these "linenum.mll" file can be removed to keep only one ? -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#926180: scilab: FTBFS on all - New trouble
On 12/05/2019 22:10, Julien Puydt wrote: > Hi, > > On 12/05/2019 11:46, Alexis Murzeau wrote: > >> I saw that there is a bugfix release 6.0.2 with many fixes [0]. > I had started to package 6.0.2 on salsa already in february. I removed > the patch about Linenum as that was supposed to have been reworked and > fixed, and it now fails with : > > ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I > ./src/xml2modelica nums.cmxa ./src/xml2modelica/xMLTree.ml > ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml > ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml > ./src/xml2modelica/xMLLexer.ml > ./src/xml2modelica/modelicaCodeGenerator.ml > ./src/xml2modelica/xML2Modelica.ml > File "./src/xml2modelica/xML2Modelica.ml", line 1: > Error: Files ./src/xml2modelica/xMLParser.cmx >and ./src/xml2modelica/linenum.cmx >make inconsistent assumptions over implementation Linenum > > ie : it looks like upstream's fix isn't correct. + upstream S
Bug#926180: scilab: FTBFS on all - New trouble - upstream bugfix release while in freeze
Hi, Le 12/05/2019 à 22:10, Julien Puydt a écrit : > Hi, > > On 12/05/2019 11:46, Alexis Murzeau wrote: > >> I saw that there is a bugfix release 6.0.2 with many fixes [0]. > > I had started to package 6.0.2 on salsa already in february. I was wondering, will such bug-fix upstream release be accepted in buster, now that we are in full freeze ? That bug-fix release seems a welcomed version given the many bugs fixed since 6.0.1, but it is not a small targeted fix release. I'm adding debian-mentors for advice about this. [0] https://help.scilab.org/docs/6.0.2/en_US/CHANGES.html#Bugs_fixed_in_6.0.2 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#926180: scilab: FTBFS on all - New trouble
Hi, On 12/05/2019 11:46, Alexis Murzeau wrote: > I saw that there is a bugfix release 6.0.2 with many fixes [0]. I had started to package 6.0.2 on salsa already in february. I removed the patch about Linenum as that was supposed to have been reworked and fixed, and it now fails with : ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I ./src/xml2modelica nums.cmxa ./src/xml2modelica/xMLTree.ml ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml ./src/xml2modelica/xMLLexer.ml ./src/xml2modelica/modelicaCodeGenerator.ml ./src/xml2modelica/xML2Modelica.ml File "./src/xml2modelica/xML2Modelica.ml", line 1: Error: Files ./src/xml2modelica/xMLParser.cmx and ./src/xml2modelica/linenum.cmx make inconsistent assumptions over implementation Linenum ie : it looks like upstream's fix isn't correct. I don't know when I'll find the time to dig it. Cheers, JP
Bug#926180: scilab: FTBFS on all - New trouble
Le 08/05/2019 à 00:50, Alexis Murzeau a écrit : > Where the working log has a java.lang.IllegalStateException > exception instead. Maybe there is a memory corruption somewhere in > native code that doesn't always cause a jvm crash. > > I fear the crash happen in java code, this stacktrace is not very good :( > > I'm trying to run that command with valgrind, but this is very slow. > Running in valgrind does not help as there are many false positive. As the crash seems to occur in JVM generated code, I think we need a java call stack to be able to see what's wrong. The thread crashing seems to be a java thread (there is only JVM + pthread in the stacktrace). In a sbuild inside a VM without X, I don't reproduce the issue. I have interrupted the build just after the "Building documentation" for en_US step to drop a bash shell, I ran the documentation build in a loop. But I didn't got any crash. I saw that there is a bugfix release 6.0.2 with many fixes [0]. As no one seems to be able to reproduce the issue, I suggest to: - Try to reproduce on the x86-bm-01 machine and retrieve a core dump to dump other thread and run jstack to get the java stacktrace and see what's wrong - Try to build the 6.0.1 version and also the new 6.0.2 version on x86-bm-01 to ensure that the crash is still reproducible with 6.0.1 and if it is fixed with 6.0.2. I didn't find any possible fixed issue in the list of fixed bugs in 6.0.2 that could match our crash without entering in each of them. => So, can anyone access the x86-bm-01 machine to try to reproduce and get a core dump of this crash ? [0] https://help.scilab.org/docs/6.0.2/en_US/CHANGES.html#Bugs_fixed_in_6.0.2 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#926180: scilab: FTBFS on all - New trouble
Le 03/05/2019 à 18:39, Sylvestre Ledru a écrit : > What about starting a xvfb during the build? > > Does it fix the issue? > > S > > > Le 03/05/2019 à 16:50, Alexis Murzeau a écrit : >> Hi, >> >> Indeed, I tried in a virtual machine: >> - install scilab >> - run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 >> SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' >> HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e >> "try xmltojar([],[],'en_US');catch disp(lasterror()); >> exit(-1);end;exit(0);"` >> >> And, while connected via ssh using Putty, I got this: >> ``` >> [snip] >> >> [6]: >> jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353) >> [7]: java.base/java.lang.Thread.run(Thread.java:834) >> commons module not found. >> graphic_objects module not found. >> ui_data module not found. >> graph module not found. >> history_browser module not found. >> slint module not found. >> coverage module not found. >> ``` >> > Despite having *almost* the same output when calling manually the command line outside of a build context, when I do a sbuild, I do not have errors as x86-bm-01 have. So I think the manual run has unrelated issues to this bug. Actually, the build that doesn't fail (on x86-csail-02) also has the GLException exception (search for "-- Building documentation (en_US) --" in the logs). The difference starts here: ``` A fatal error has been detected by Scilab. Please check your user-defined functions (or external module ones) should they appear in the stack trace. Otherwise you can report a bug on http://bugzilla.scilab.org/ with: * a sample code which reproduces the issue * the result of [a, b] = getdebuginfo() * the following information: [x86-bm-01:08312] Signal: Illegal instruction (4) [x86-bm-01:08312] Signal code: Illegal operand (2) [x86-bm-01:08312] Failing at address: 0x7ff0c87e3dcf Call stack: 1: 0xb2d791 (/usr/lib/jvm/default-java/lib/server/libjvm.so) 2: 0xb222b8 < > (/usr/lib/jvm/default-java/lib/server/libjvm.so) 3: 0x12730 < > (/lib/x86_64-linux-gnu/libpthread.so.0) 4: ??(?) End of stack ``` Where the working log has a java.lang.IllegalStateException exception instead. Maybe there is a memory corruption somewhere in native code that doesn't always cause a jvm crash. I fear the crash happen in java code, this stacktrace is not very good :( I'm trying to run that command with valgrind, but this is very slow. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#926180: scilab: FTBFS on all - New trouble
What about starting a xvfb during the build? Does it fix the issue? S Le 03/05/2019 à 16:50, Alexis Murzeau a écrit : Hi, Indeed, I tried in a virtual machine: - install scilab - run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e "try xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"` And, while connected via ssh using Putty, I got this: ``` LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e "try xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);" Picked up _JAVA_OPTIONS: -Djava.class.path=/usr/share/java/flexdock.jar:/usr/share/java/skinlf.jar:/usr/share/java/looks.jar:/usr/share/java/commons-logging.jar:/usr/share/java/jhall.jar:/usr/share/java/lucene-core-4.10.4.jar:/usr/share/java/lucene-analyzers-common-4.10.4.jar:/usr/share/java/lucene-queryparser-4.10.4.jar:/usr/share/maven-repo/org/freehep/freehep-util/debian/freehep-util-debian.jar:/usr/share/maven-repo/org/freehep/freehep-io/debian/freehep-io-debian.jar:/usr/share/maven-repo/org/freehep/freehep-graphicsio/debian/freehep-graphicsio-debian.jar:/usr/share/java/freehep-graphicsio-emf-2.1.jar:/usr/share/java/freehep-graphics2d-2.1.1.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta-engine-1.0.4.jar:/usr/share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java/gluegen2-rt.jar:/usr/share/java/jeuclid-core.jar:/usr/share/java/jlatexmath-fop-1.0.7.jar:/usr/share/java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik.jar:/usr/share/java/xml-apis-ext.jar:/usr/share/java/commons-io.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/avalon-framework.jar:/usr/share/java/jlatexmath-1.0.7.jar:/usr/share/java/ecj.jar:/usr/share/java/javax.activation.jar:/usr/share/java/jaxb-runtime.jar:/usr/share/scilab/modules/commons/jar/org.scilab.modules.commons.jar:/usr/share/scilab/modules/xcos/jar/org.scilab.modules.xcos.jar:/usr/share/scilab/modules/renderer/jar/org.scilab.modules.renderer.jar:/usr/share/scilab/modules/scirenderer/jar/scirenderer.jar:/usr/share/scilab/modules/helptools/jar/org.scilab.modules.helptools.jar:/usr/share/scilab/modules/helptools/jar/scilab_images.jar:/usr/share/scilab/modules/helptools/jar/scilab_ru_RU_help.jar:/usr/share/scilab/modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:/usr/share/scilab/modules/javasci/jar/org.scilab.modules.javasci.jar:/usr/share/scilab/modules/scinotes/jar/org.scilab.modules.scinotes.jar:/usr/share/scilab/modules/graphic_objects/jar/org.scilab.modules.graphic_objects.jar:/usr/share/scilab/modules/history_browser/jar/org.scilab.modules.history_browser.jar:/usr/share/scilab/modules/history_manager/jar/org.scilab.modules.history_manager.jar:/usr/share/scilab/modules/core/jar/org.scilab.modules.core.jar:/usr/share/scilab/modules/graph/jar/org.scilab.modules.graph.jar:/usr/share/scilab/modules/action_binding/jar/org.scilab.modules.action_binding.jar:/usr/share/scilab/modules/localization/jar/org.scilab.modules.localization.jar:/usr/share/scilab/modules/external_objects_java/jar/org.scilab.modules.external_objects_java.jar:/usr/share/scilab/modules/ui_data/jar/org.scilab.modules.ui_data.jar:/usr/share/scilab/modules/console/jar/org.scilab.modules.console.jar:/usr/share/scilab/modules/gui/jar/org.scilab.modules.gui.jar:/usr/share/scilab/modules/preferences/jar/org.scilab.modules.preferences.jar:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar:/usr/share/scilab/modules/completion/jar/org.scilab.modules.completion.jar:/usr/share/scilab/modules/types/jar/org.scilab.modules.types.jar: -Djava.awt.headless=true WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.scilab.modules.jvm.LibraryPath (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) to field java.lang.ClassLoader.sys_paths WARNING: Please consider reporting this to the maintainers of org.scilab.modules.jvm.LibraryPath WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol Caught handled GLException: EGLGLXDrawableFactory - Could not initialize shared resources for EGLGraphicsDevice[type .egl, v0.0.0, connection nil, unitID 0, handle 0x0, owner true, ResourceToolkitLock[obj 0x1e0498a7, isOwner true, <4e857949, 665b7ef5>[count 1, qsz 0, owner ]]] on thread main-SharedResourceRunner [0]:
Bug#926180: scilab: FTBFS on all - New trouble
Hi, Indeed, I tried in a virtual machine: - install scilab - run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e "try xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"` And, while connected via ssh using Putty, I got this: ``` LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e "try xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);" Picked up _JAVA_OPTIONS: -Djava.class.path=/usr/share/java/flexdock.jar:/usr/share/java/skinlf.jar:/usr/share/java/looks.jar:/usr/share/java/commons-logging.jar:/usr/share/java/jhall.jar:/usr/share/java/lucene-core-4.10.4.jar:/usr/share/java/lucene-analyzers-common-4.10.4.jar:/usr/share/java/lucene-queryparser-4.10.4.jar:/usr/share/maven-repo/org/freehep/freehep-util/debian/freehep-util-debian.jar:/usr/share/maven-repo/org/freehep/freehep-io/debian/freehep-io-debian.jar:/usr/share/maven-repo/org/freehep/freehep-graphicsio/debian/freehep-graphicsio-debian.jar:/usr/share/java/freehep-graphicsio-emf-2.1.jar:/usr/share/java/freehep-graphics2d-2.1.1.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta-engine-1.0.4.jar:/usr/share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java/gluegen2-rt.jar:/usr/share/java/jeuclid-core.jar:/usr/share/java/jlatexmath-fop-1.0.7.jar:/usr/share/java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik.jar:/usr/share/java/xml-apis-ext.jar:/usr/share/java/commons-io.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/avalon-framework.jar:/usr/share/java/jlatexmath-1.0.7.jar:/usr/share/java/ecj.jar:/usr/share/java/javax.activation.jar:/usr/share/java/jaxb-runtime.jar:/usr/share/scilab/modules/commons/jar/org.scilab.modules.commons.jar:/usr/share/scilab/modules/xcos/jar/org.scilab.modules.xcos.jar:/usr/share/scilab/modules/renderer/jar/org.scilab.modules.renderer.jar:/usr/share/scilab/modules/scirenderer/jar/scirenderer.jar:/usr/share/scilab/modules/helptools/jar/org.scilab.modules.helptools.jar:/usr/share/scilab/modules/helptools/jar/scilab_images.jar:/usr/share/scilab/modules/helptools/jar/scilab_ru_RU_help.jar:/usr/share/scilab/modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:/usr/share/scilab/modules/javasci/jar/org.scilab.modules.javasci.jar:/usr/share/scilab/modules/scinotes/jar/org.scilab.modules.scinotes.jar:/usr/share/scilab/modules/graphic_objects/jar/org.scilab.modules.graphic_objects.jar:/usr/share/scilab/modules/history_browser/jar/org.scilab.modules.history_browser.jar:/usr/share/scilab/modules/history_manager/jar/org.scilab.modules.history_manager.jar:/usr/share/scilab/modules/core/jar/org.scilab.modules.core.jar:/usr/share/scilab/modules/graph/jar/org.scilab.modules.graph.jar:/usr/share/scilab/modules/action_binding/jar/org.scilab.modules.action_binding.jar:/usr/share/scilab/modules/localization/jar/org.scilab.modules.localization.jar:/usr/share/scilab/modules/external_objects_java/jar/org.scilab.modules.external_objects_java.jar:/usr/share/scilab/modules/ui_data/jar/org.scilab.modules.ui_data.jar:/usr/share/scilab/modules/console/jar/org.scilab.modules.console.jar:/usr/share/scilab/modules/gui/jar/org.scilab.modules.gui.jar:/usr/share/scilab/modules/preferences/jar/org.scilab.modules.preferences.jar:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar:/usr/share/scilab/modules/completion/jar/org.scilab.modules.completion.jar:/usr/share/scilab/modules/types/jar/org.scilab.modules.types.jar: -Djava.awt.headless=true WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.scilab.modules.jvm.LibraryPath (file:/usr/share/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) to field java.lang.ClassLoader.sys_paths WARNING: Please consider reporting this to the maintainers of org.scilab.modules.jvm.LibraryPath WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol PuTTY X11 proxy: Unsupported authorisation protocol Caught handled GLException: EGLGLXDrawableFactory - Could not initialize shared resources for EGLGraphicsDevice[type .egl, v0.0.0, connection nil, unitID 0, handle 0x0, owner true, ResourceToolkitLock[obj 0x1e0498a7, isOwner true, <4e857949, 665b7ef5>[count 1, qsz 0, owner ]]] on thread main-SharedResourceRunner [0]: jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createSharedResource(EGLDrawableFactory.java:518) [1]:
