Bug#926180: scilab: FTBFS on all
Some more testing: * When run normally, or in gdb with "handle SIGSEGV nostop pass", 6.0.1 has the IllegalStateExceptions and undocumented macro warnings, 6.0.2 does not; both finish. * valgrind --smc-check=all crashes at about the same place as this bug (but with a segmentation fault instead of illegal instruction) in 6.0.1, *later* but with the same message in 6.0.2. Applying the promising-looking commits (66eff04a50, 4fadeff2ea, ef32e66c83, 62afc99d6c, eca8e3d5f5, 92739afffb, 3014d410b3, b3016a0611) as a patch to 6.0.1 does *not* change this. * valgrind --smc-check=all --vex-iropt-register-updates=allregs-at-mem-access (which the valgrind documentation suggests may be needed for SIGSEGV-catching programs, which Java is) gets past where this bug would happen in 6.0.1, then starts using >6GB of memory, near-hanging the system. * qemu-x86_64-static -cpu Opteron_G3 (to match x86-bm-01, but as previously noted, qemu does not properly reject unsupported instructions) has the opposite behaviour: it crashes earlier on 6.0.2, hangs later (after this bug would happen, using a full CPU core) on 6.0.1. * qemu+gdb crashes early in both 6.0.1 and 6.0.2. The main packaging difference between 6.0.1 and 6.0.2 appears to be removed patches; I haven't checked if the patches in question are already included in 6.0.2. # valgrind, 6.0.1 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:modules/graphic_objects/jar/org.scilab.modules.graphic_objects.jar:modules/core/jar/org.scilab.modules.core.jar:modules/renderer/jar/org.scilab.modules.renderer.jar:modules/action_binding/jar/org.scilab.modules.action_binding.jar:modules/helptools/jar/scilab_pt_BR_help.jar:modules/helptools/jar/scilab_en_US_help.jar:modules/helptools/jar/scilab_fr_FR_help.jar:modules/helptools/jar/scilab_ja_JP_help.jar:modules/helptools/jar/scilab_images.jar:modules/helptools/jar/org.scilab.modules.helptools.jar:modules/helptools/jar/scilab_ru_RU_help.jar:modules/history_browser/jar/org.scilab.modules.history_browser.jar:modules/external_objects_java/jar/org.scilab.modules.external_objects_java.jar:modules/external_objects_java/tests/libintl.jar:modules/localization/jar/org.scilab.modules.localization.jar:modules/commons/jar/org.scilab.modules.commons.jar:modules/graph/jar/org.scilab.modules.graph.jar:modules/scinotes/jar/org.scilab.modules.scinotes.jar:modules/types/jar/org.scilab.modules.types.jar:modules/ui_data/jar/org.scilab.modules.ui_data.jar:modules/gui/jar/org.scilab.modules.gui.jar:modules/console/jar/org.scilab.modules.console.jar:modules/history_manager/jar/org.scilab.modules.history_manager.jar:modules/xcos/jar/org.scilab.modules.xcos.jar:modules/preferences/jar/org.scilab.modules.preferences.jar:modules/completion/jar/org.scilab.modules.completion.jar:modules/jvm/jar/org.scilab.modules.jvm.jar:modules/scirenderer/jar/scirenderer.jar:modules/javasci/jar/org.scilab.modules.javasci.jar:modules/graphic_export/jar/org.scilab.modules.graphic_export.jar: -Djava.awt.headless=true WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.scilab.modules.jvm.LibraryPath (file:/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.1/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 Building the Scilab manual master document for en_US. Building the scilab manual file [javaHelp] Warning: the macro message is used in an example and is undocumented (rmdir.xml). Warning: the macro message is used in an example
Bug#926180: scilab: FTBFS on all
Some further searching suggests that Java triggers and catches SIGSEGVs as part of normal operation, and hence is expected to not work under gdb without "handle SIGSEGV nostop pass". With this, both 6.0.1 and 6.0.2 don't crash in gdb, i.e. the crash in gdb probably isn't this bug. This suggests that the bug could be a subtle kind of baseline violation: some assumption that fails on Valgrind's and qemu's emulated CPUs and very old real CPUs. (As noted above, 6.0.2 does crash in Valgrind.) It also still could be memory corruption that happens not to trigger on recent real CPUs, or that is in a code path only used on older CPUs. I haven't investigated how Ubuntu's 6.0.2 packaging differs from the failed attempt at 6.0.2 reported above, or whether it fixes any of our other bugs. However, as the freeze rules do not allow it by default, I suggest not uploading it to unstable without asking release team *first*.
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
On 23/05/2019 22:35, Rebecca N. Palmer wrote: It now looks like these are actually "valgrind doesn't understand Java memory allocation" The Valgrind documentation says --smc-check=all should fix this, but it doesn't. Ubuntu has a 6.0.2 package that builds in Debian, but it still has this bug. (Same stacktrace as 6.0.1 under gdb; once a different one (below) under valgrind --smc-check=all --error-limit=no --log-file=scilab_valgrind%n .) WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.scilab.modules.jvm.LibraryPath (file:/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/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 terminate called after throwing an instance of 'GiwsException::JniCallMethodException' what(): Exception when calling Java method : at java.base/java.util.TreeMap.getEntry(TreeMap.java:350) at java.base/java.util.TreeMap.containsKey(TreeMap.java:231) at java.base/java.util.TreeSet.contains(TreeSet.java:234) at org.scilab.modules.graphic_objects.utils.MenuBarBuilder$MenuBarConfigurationHandler.invoke(Unknown Source) at com.sun.proxy.$Proxy0.addMenus(Unknown Source) at org.scilab.modules.graphic_objects.utils.MenuBarBuilder.buildMenuBar(Unknown Source) at org.scilab.modules.graphic_objects.utils.MenuBarBuilder.buildFigureMenuBar(Unknown Source) at org.scilab.modules.graphic_objects.CallGraphicController.buildFigureMenuBar(Unknown Source) at java.base/java.util.TreeMap.getEntry(TreeMap.java:350) at java.base/java.util.TreeMap.containsKey(TreeMap.java:231) at java.base/java.util.TreeSet.contains(TreeSet.java:234) at org.scilab.modules.graphic_objects.utils.MenuBarBuilder$MenuBarConfigurationHandler.invoke(Unknown Source) at com.sun.proxy.$Proxy0.addMenus(Unknown Source) at org.scilab.modules.graphic_objects.utils.MenuBarBuilder.buildMenuBar(Unknown Source) at org.scilab.modules.graphic_objects.utils.MenuBarBuilder.buildFigureMenuBar(Unknown Source) at org.scilab.modules.graphic_objects.CallGraphicController.buildFigureMenuBar(Unknown Source) 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: [rnpalmer-laptop:05275] Signal: Aborted (6) [rnpalmer-laptop:05275] Signal code: (-6) Call stack: 1: 0x377bb (/lib/x86_64-linux-gnu/libc.so.6) 2: 0x22535 (/lib/x86_64-linux-gnu/libc.so.6) 3: 0x8c983 < > (/usr/lib/x86_64-linux-gnu/libstdc++.so.6) 4: 0x928c6 < > (/usr/lib/x86_64-linux-gnu/libstdc++.so.6) 5: 0x92901 < > (/usr/lib/x86_64-linux-gnu/libstdc++.so.6) 6: 0x92b34 < > (/usr/lib/x86_64-linux-gnu/libstdc++.so.6) 7: 0x1e0d6 int)> (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/modules/graphic_objects/.libs/libscigraphic_objects.so.6) 8: 0x6525e (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/modules/graphics/.libs/libscigraphics.so.6) 9: 0x66180 (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/modules/graphics/.libs/libscigraphics.so.6) 10: 0x49c33 (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/modules/graphics/.libs/libscigraphics.so.6) 11: 0x1b9694 (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/modules/.libs/libscilab-cli.so.6) 12: 0x2360 (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/.libs/scilab-bin) 13: 0x2409b <__libc_start_main> (/lib/x86_64-linux-gnu/libc.so.6) 14: 0x2dfa < > (/home/rnpalmer/Debian/builds/stackbuild/scilab-6.0.2/.libs/scilab-bin) End of stack Last error (of ~10,000) in the Valgrind log: ==5275== Invalid write of size 4 ==5275==at 0x2D810AE8: ??? ==5275==by 0x5907680: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so) ==5275==by 0x5976F8C: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so) ==5275==by 0x597874D: ??? (in /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so) ==5275==by 0x4EA1C12: JNIEnv_::CallObjectMethod(_jobject*, _jmethodID*, ...) (jni.h:906) ==5275==by 0x4EA0CBB: GiwsException::JniException::retrieveExceptionName[abi:cxx11](JNIEnv_*) (GiwsException.cpp:217) ==5275==by 0x4EA0F6F: GiwsException::JniException::JniException(JNIEnv_*) (GiwsException.cpp:37) ==5275==by 0x4EA1830: GiwsException::JniCallMethodException::JniCallMethodException(JNIEnv_*) (GiwsException.cpp:288) ==5275==by 0x4FF50BF: org_scilab_modules_graphic_objects::CallGraphicController::buildFigureMenuBar(JavaVM_*,
Bug#926180: scilab: FTBFS on all
* valgrind: reports a _lot_ of invalid memory accesses, It now looks like these are actually "valgrind doesn't understand Java memory allocation" - 'valgrind jdb' and 'valgrind jar' also report large numbers of "invalid" accesses. However, the segfaults are still evidence that this is memory corruption, not baseline violation.
Bug#926180: scilab: FTBFS on all
Control: found -1 6.0.1-10
(I suggest opening a new bug for the 6.0.2 issues: as noted above, that
probably won't be accepted for buster even if we do get it to build.)
Running what I think is the relevant step in a debugger:
* Go to the top level directory of a _built_ source tree (i.e. one that
has had dpkg-buildpackage run on it; the same such tree can be used more
than once)
* Open the script file scilab-bin, and at line 117 (in function
func_exec_program_core), replace
-exec "$progdir/$program" ${1+"$@"}
+exec gdb --args "$progdir/$program" ${1+"$@"}
(or whatever debugging tool you want to use).
* Run:
LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1
_JAVA_OPTIONS='-Djava.awt.headless=true' ./bin/scilab-adv-cli
-noatomsautoload -nb -l en_US -nouserstartup -e "try
xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"
Results:
* no debugging tool: succeeds (for me), with the usual nonfatal
IllegalStateException.
* qemu-x86_64-static -cpu Opteron_G3 (probably what x86-bm-01 has [0],
but note that qemu *doesn't* reject instructions that the CPU model
emulated doesn't have [1]): hangs using a full core of CPU.
* gdb: crashes with segfault and corrupt-stack backtrace,
Thread 1 "scilab-bin" received signal SIGSEGV, Segmentation fault.
0x7fffc096851b in ?? ()
(gdb) bt full
#0 0x7fffc096851b in ?? ()
No symbol table info available.
#1 0x0206 in ?? ()
No symbol table info available.
#2 0x7fffc0968280 in ?? ()
No symbol table info available.
#3 0x776c5034 in Abstract_VM_Version::_vm_major_version ()
from /usr/lib/jvm/default-java/lib/server/libjvm.so
No symbol table info available.
#4 0x7fffbe10 in ?? ()
No symbol table info available.
#5 0x773317ca in VM_Version::get_processor_features ()
at ./src/hotspot/cpu/x86/vm_version_x86.cpp:565
use_avx_limit =
buf =
"P\372]UUU\000\000\000\000\000\000\000\000\000\000\004\f\000\000\000\000\000\000\320\335\062\367\377\177\000\000\001\000\000\000\004",
'\000' , "\020", '\000' ,
"\310\235C\367\377\177\000\000\327\234C\367\377\177\000\000\001", '\000'
, "
vq\367\377\177\000\000\002\000\000\000\000\000\000\000S\000\000\000\032",
'\000' ,
"p\372]UUU\000\000p\372]UUU\000\000\000\000\000\000\000\000\000\000"...
use_sse_limit =
cache_line_size =
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
* valgrind: reports a _lot_ of invalid memory accesses, then crashes
with segfault
* (jvm doesn't work - .libs/scilab-bin is a native executable, not a
Java file)
This suggests that it is memory corruption after all: the "illegal
instruction" might be a corrupt stack returning to somewhere that was
never meant to be executable code.
[0] https://lists.debian.org/debian-wb-team/2019/05/msg4.html
[1] https://bugs.launchpad.net/qemu/+bug/1818075
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 - baseline violation?
Given that the error is "Illegal instruction", and reproducibly happens on x86-bm-01 and not the other machines we've tried, could it be something assuming CPU features more recent than the amd64 baseline? If so, it's not obvious where: scilab does contain some C/C++ code (as well as Java), but there aren't any asm() or __builtin_ia32* calls in it, or any -march options in the build log. Maybe it's in a dependency, not scilab itself? There is an open "illegal instruction crash in Xcos" bug upstream, which may or may not be related: https://bugzilla.scilab.org/show_bug.cgi?id=11003#c6 Alexis Murzeau wrote: will such bug-fix upstream release be accepted in buster, now that we are in full freeze ? Generally not: Debian prefers not to fix minor bugs during freeze because this might accidentally create major ones. https://release.debian.org/buster/freeze_policy.html
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
Control: tags -1 moreinfo I don't see this in a DIST=sid cowbuilder --build scilab_6.0.1-9.dsc --binary-indep build: has it been fixed (the -8 to -9 changelog suggests not), or does my setup allow enough graphics access to not have it? If the bug does still exist, can someone affected try adding xvfb and xauth to Build-Depends? That might help.
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]:
Bug#926180: scilab: FTBFS on all
package: src:scilab version: 6.0.1-7 severity: serious tags: ftbfs Hi, The latest version of scilab in unstable fails on all: https://buildd.debian.org/status/logs.php?pkg=scilab=all I don't see any relevant changes that might cause this, so I'm filing this bug against the version in testing (even though that one builds fine). If it turns out to be related to the new version, feel free to update the version information. All the packages installed during the buils of 6.0.1-8 seem to be identical. The only difference is that all previous attempts were done on buildd x86-csail-02, while the failing builds are done on x86-bm-01. Cheers, Ivo
