[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179
--- Comment #28 from Nikita Sirgienko ---
I had reproduced the issue, in some sense.
1. Build Cantor with my Julia v1.0.0
2. Then, without 'make clean', rerun cmake with JULIA_EXECUTABLE points to
julia v1.1.0 (or remove julia v1.0.0 and install julia v1.1.0)
3. Build Cantor (it's not actually full rebuild, so it passes quickly)
4. Install
Now we have corrupted Julia backend: cantor_juliaserver will crash on any Julia
error and Cantor will never finish evaluation on entry with error code.
Second moment, it's a GR julia module, which Cantor uses for embedded graphic.
Important, that Cantor don't check GR precense and just import GR module,
which, if GR module not installed, cause *julia error*. Often is not a problem,
we just got an error, handle it and continue to work.
Important, that Cantor does this import *before* running user code from first
user code entry.
As can be seen, synergy of this two problems cause unending login (Cantor done
login, send import code, server crashs and Cantor never finish computing first
user code entry), that you describe in this bug report.
There is a easy way to check, if I am right about your problem: you need go to
Julia settings and disable 'Integrate Plots in Worksheet' checkbox.
If after this you could login in julia (for example, with code `print("Hello
world!")`), then we successfully localized your problem.
--
You are receiving this mail because:
You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #27 from Nikita Sirgienko --- What about cantor_juliaserver process? Is he alive, when Cantor starts hanging on "Calculation"? -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #26 from Nikita Sirgienko --- Well, looks the problem appears after login in first expression evaluation. Intresting. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179
--- Comment #25 from vialav ---
Your suggestion was timely:
My system has exported:
QT_LOGGING_RULES=*.debug=false
But that was meant essentially to preserve the only debug output. It puzzles me
what the 'debug' output was that or it wasn't.
Unsetting QT_LOGGING_RULES started to produce the desired [non-debug?] output:
─── Output/messages
───
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/16/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/22/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/24/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/32/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/48/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/64/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/128/"
dir: "/usr/lib/x86_64-linux-gnu/qt5/plugins/cantor/backends"
Creating MaximaBackend
Creating NullBackend
Creating PythonBackend
Creating PythonBackend
Creating RBackend
Creating SageBackend
Creating ScilabBackend
dir: "/usr/bin/cantor/backends"
"Julia" true true
"KAlgebra" true true
"Lua" true true
"Maxima" true true
"nullbackend" false true
"Octave" true true
"Python 2" true true
"Python 3" true true
"Qalculate" true true
"R" true true
"Sage" true true
"Scilab" true true
Backend "Julia" offers extensions: ("VariableManagementExtension",
"PackagingExtension", "PlotExtension", "ScriptExtension",
"LinearAlgebraExtension")
JuliaSession(0x4abe20) Cantor::VariableManagementExtension(0x95f800, name =
"VariableManagementExtension")
new worksheetaccess interface
loading assistants...
dir: "/usr/lib/x86_64-linux-gnu/qt5/plugins/cantor/assistants"
plugin "AdvancedPlot" is not supported by "Julia"
plugin "Create Matrix" is supported by "Julia" , requires extensions
("LinearAlgebraExtension")
plugin "Differentiate" is not supported by "Julia"
plugin "Eigenvalues" is not supported by "Julia"
plugin "Eigenvectors" is not supported by "Julia"
plugin "Import Package" is supported by "Julia" , requires extensions
("PackagingExtension")
plugin "Integrate" is not supported by "Julia"
plugin "Invert Matrix" is not supported by "Julia"
plugin "Plot2d" is supported by "Julia" , requires extensions
("PlotExtension")
plugin "Plot3d" is supported by "Julia" , requires extensions
("PlotExtension")
plugin "QalculatePlot" is not supported by "Julia"
plugin "RunScript" is supported by "Julia" , requires extensions
("ScriptExtension")
plugin "Solve" is not supported by "Julia"
dir: "/usr/bin/cantor/assistants"
loading panel plugins for session of type "Julia"
dir: "/usr/lib/x86_64-linux-gnu/qt5/plugins/cantor/panels"
plugin "Help" is supported, requires extensions ("")
plugin "Variable Manager" is supported, requires extensions
("VariableManagementExtension")
dir: "/usr/bin/cantor/panels"
Entry Appended
adding panel for "Help"
adding panel for "Variable Manager" # here I've entered 1+1 and pressed
Shift+Enter -->
ShortcutOverride 16777220 QFlags(ShiftModifier)
[Detaching after fork from child process 24404]
wsStatusChange 1
login to julia 1.2.0-rc1 done
wsStatusChange 0
# (process is hanging on "Calculating…"; next I click File -> Exit):
Thread 1 "cantor" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
─── Assembly
──
Cannot access memory at address 0x0
─── Expressions
───
─── History
───
─── Memory
─── Registers
─
rax 0xrbx 0x00e1d1c0rcx 0x7fffbe20
rdx 0x7774f440rsi 0x7fffbe70rdi 0x0050e600
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #24 from vialav --- ok, thanks for a hint As a sidenote: No, it is not the way I've got the source. Following the standard procedure of 'git-cloning' (with no merging), and compiling with clang-9 in this last case (with full debug on), then File -> Exit after the Julia session hangs up, all with gdb and debug symbols (and full absence of the Qt-debug output): ─── Output/messages ─── Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/16/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/22/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/24/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/32/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/48/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/64/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/128/" [Detaching after fork from child process 21264] Thread 1 "cantor" received signal SIGSEGV, Segmentation fault. 0x in ?? () ─── Assembly ── Cannot access memory at address 0x0 ─── Expressions ─── ─── History ─── ─── Memory ─── Registers ─ rax 0xrbx 0x00e24eb0rcx 0x7fffbdf0 rdx 0x7774f440rsi 0x7fffbe40rdi 0x005f7380 rbp 0x7fffbde0rsp 0x7fffbce8 r8 0x r9 0x0006r10 0x r11 0x0004r12 0x005f7380r13 0x00e00a70 r14 0x00c4aaf0r15 0x767cc360 rip 0x eflags [ IF RF ] cs 0x0033 ss 0x002b ds 0x es 0x fs 0x gs 0x ─── Source ─── Stack ─ [0] from 0x (no arguments) [1] from 0x7633b77f in QMetaObject::activate(QObject*, int, int, void**) (no arguments) [+] ─── Threads ─── [6] id 21260 name cantor:disk$0 from 0x75c7a3bb in futex_wait_cancelable+27 at ../sysdeps/unix/sysv/linux/futex-internal.h:88 [5] id 21257 name QDBusConnection from 0x75da3ba9 in __GI___poll+73 at ../sysdeps/unix/sysv/linux/poll.c:29 [4] id 21256 name gdbus from 0x75da3ba9 in __GI___poll+73 at ../sysdeps/unix/sysv/linux/poll.c:29 [3] id 21255 name gmain from 0x75da3ba9 in __GI___poll+73 at ../sysdeps/unix/sysv/linux/poll.c:29 [2] id 21251 name QXcbEventReader from 0x75da3ba9 in __GI___poll+73 at ../sysdeps/unix/sysv/linux/poll.c:29 [1] id 21244 name cantor from 0x ─── >>> >>> bt #0 0x in () #1 0x7633b77f in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x77c863f5 in KParts::Part::setStatusBarText(QString
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #23 from Nikita Sirgienko --- Arg, I remembered, that a few years ago, I need to change system qt policy, because Debian (and Ubuntu too) had starts suppress qt debug messages. See https://bugzilla.redhat.com/show_bug.cgi?id=1227295, I think Cantor is actually builded in debug mode, but OS supress all debug messages. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #22 from vialav --- So, it is, likely, how I've got a source?… with clang-9: #0 0x in () #1 0x7633b77f in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x77c863f5 in KParts::Part::setStatusBarText(QString const&) () at /usr/lib/x86_64-linux-gnu/libKF5Parts.so.5 #3 0x7fffc659717f in CantorPart::setStatusMessage(QString const&) (this=0xcabc50, message=...) at ./src/cantor_part.cpp:947 #4 0x7fffc659717f in CantorPart::worksheetStatusChanged(Cantor::Session::Status) (this=0xcabc50, status=) at ./src/cantor_part.cpp:595 #5 0x7fffc6587497 in CantorPart::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x5b4a20, _c=, _id=, _a=0x7fffbdf0) at ./obj-x86_64-linux-gnu/src/cantorpart_autogen/EWIEGA46WW/moc_cantor_part.cpp:209 #6 0x7633b665 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x77cf7dfc in Cantor::Session::statusChanged(Cantor::Session::Status) (this=0x5b4a20, _t1=) at ./obj-x86_64-linux-gnu/src/lib/cantorlibs_autogen/EWIEGA46WW/moc_session.cpp:164 #8 0x7fffdb2602b7 in JuliaSession::interrupt() (this=0xc882f0) at ./src/backends/julia/juliasession.cpp:158 #9 0x7fffdb25ffad in JuliaSession::logout() (this=0xc882f0) at ./src/backends/julia/juliasession.cpp:133 #10 0x7fffc659cf11 in Worksheet::~Worksheet() (this=0xca6cf0) at ./src/worksheet.cpp:107 #11 0x7fffc659d069 in Worksheet::~Worksheet() (this=0xca6cf0) at ./src/worksheet.cpp:101 #12 0x7633924b in QObjectPrivate::deleteChildren() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x770c4d5c in QWidget::~QWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #14 0x770c4f99 in QWidget::~QWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x7633924b in QObjectPrivate::deleteChildren() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x770c4d5c in QWidget::~QWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x772343b9 in QStackedWidget::~QStackedWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x7633924b in QObjectPrivate::deleteChildren() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x770c4d5c in QWidget::~QWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #20 0x772552a9 in QTabWidget::~QTabWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #21 0x7633924b in QObjectPrivate::deleteChildren() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x770c4d5c in QWidget::~QWidget() () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #23 0x77b4ea14 in KMainWindow::~KMainWindow() () at /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5 #24 0x0040d710 in CantorShell::~CantorShell() (this=0x5b4a20) at ./obj-x86_64-linux-gnu/src/cantor_autogen/EWIEGA46WW/../../../../src/cantor.h:56 #25 0x0040d710 in CantorShell::~CantorShell() (this=0x5b4a20) at ./obj-x86_64-linux-gnu/src/cantor_autogen/EWIEGA46WW/../../../../src/cantor.h:56 #26 0x7633c1f0 in QObject::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #27 0x770c975b in QWidget::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #28 0x771dcc6b in QMainWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #29 0x77b50feb in KMainWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5 #30 0x77b9d147 in KXmlGuiWindow::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libKF5XmlGui.so.5 #31 0x7708a83c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #32 0x77092104 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #33 0x7630c9e8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #34 0x7630f15d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #35 0x76366373 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #36 0x72d20417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #37 0x72d20650 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #38 0x72d206dc in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #39 0x7636599f in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #40 0x7630aa1a in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #41 0x76313ac4 in QCoreApplication::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #42 0x0040fb02 in main(int, char**) (argc=, argv=) at ./src/main.cpp:156 -- You are receiving this mail because: You
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179
--- Comment #21 from vialav ---
Might it be a compiler (gcc-9 in my case, I may try it with clang)? I turned
off all the optimizations, hardening, and explicitly requested
export DEB_BUILD_MAINT_OPTIONS = noopt
… -DCMAKE_BUILD_TYPE=debug
Running Cantor with gdb and debug symbols {all compiled with commented out the
line "add_definitions(-DQT_NO_DEBUG_OUTPUT)"} did not change the output.
Clicking File -> Exit after trying to start Julia session (hanged in the air),
I've caught up, possibly unrelated, a SIGSEGV:
─── Output/messages
───
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/16/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/22/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/24/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/32/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/48/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/64/"
Invalid Context= "stock" line for icon theme:
"/usr/share/icons/ubuntu-mono-dark/stock/128/"
[Detaching after fork from child process 5601]
Thread 1 "cantor" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
─── Assembly
──
Cannot access memory at address 0x0
─── Expressions
───
─── History
───
─── Memory
─── Registers
─
rax 0xrbx 0x55f77fd0rcx 0x7fffbca0
rdx 0x7774d440rsi 0x7fffbcd8rdi 0x556f3dd0
rbp 0x7fffbc90rsp 0x7fffbb98
r8 0x r9 0x0004r10 0x
r11 0x0004r12 0x556f3dd0r13 0x55f63460
r14 0x55da8b50r15 0x767ca160
rip 0x eflags [ IF RF ] cs 0x0033
ss 0x002b ds 0x es 0x
fs 0x gs 0x
─── Source
─── Stack
─
[0] from 0x
(no arguments)
[1] from 0x7633977f in QMetaObject::activate(QObject*, int, int,
void**)
(no arguments)
[+]
─── Threads
───
[6] id 5591 name cantor:disk$0 from 0x75c783bb in
futex_wait_cancelable+27 at ../sysdeps/unix/sysv/linux/futex-internal.h:88
[5] id 5589 name QDBusConnection from 0x75da1ba9 in __GI___poll+73 at
../sysdeps/unix/sysv/linux/poll.c:29
[4] id 5588 name gdbus from 0x75da1ba9 in __GI___poll+73 at
../sysdeps/unix/sysv/linux/poll.c:29
[3] id 5587 name gmain from 0x75da1ba9 in __GI___poll+73 at
../sysdeps/unix/sysv/linux/poll.c:29
[2] id 5586 name QXcbEventReader from 0x75da1ba9 in __GI___poll+73 at
../sysdeps/unix/sysv/linux/poll.c:29
[1] id 5581 name cantor from 0x
───
>>> backtrace
#0 0x in ()
#1 0x7633977f in
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #20 from vialav --- Ok, because compiling with the only flag: # see FEATURE AREAS in dpkg-buildflags(1) export DEB_BUILD_MAINT_OPTIONS = hardening=+all …I've got essentially the same results, again, then it must me the main suspect. Removing it, and re-compiling, again. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #19 from vialav --- I'm turning all the optimization off, commenting out, and will post the result. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #18 from Nikita Sirgienko --- (In reply to vialav from comment #16) > #(so, CMAKE_BUILD_TYPE only once and Debug, but what the heck where is the > output…) Strange, I recommend go to CMakeLists.txt, found the line "add_definitions(-DQT_NO_DEBUG_OUTPUT)" and comment it. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #17 from Nikita Sirgienko --- (In reply to vialav from comment #16) > Ok, that 'None' did come from Debian 'automagic', I didn't set it on > purpose. However, the second (for me the only one) -DCMAKE_BUILD_TYPE=debug > shadows (rewrites anew) ehm… the CMAKE_BUILD_TYPE, so, it shall be the Debug > build in the result (even *debug.cmake hints on this). I had tested that happends, if cmake got two CMAKE_BUILD_TYPE (even second is 'debug'). With two definitions Cantor don't produced debug output. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #16 from vialav --- Ok, that 'None' did come from Debian 'automagic', I didn't set it on purpose. However, the second (for me the only one) -DCMAKE_BUILD_TYPE=debug shadows (rewrites anew) ehm… the CMAKE_BUILD_TYPE, so, it shall be the Debug build in the result (even *debug.cmake hints on this). And here is how I've got the source : git clone --recurse-submodules git://anongit.kde.org/cantor.git git checkout origin/Applications/19.04 git merge master # resolve a trivial merge conflict in CMakeLists.txt (set a version) # build as in the attached log #my **naive** debian/rules universal template: #!/usr/bin/make -f # see FEATURE AREAS in dpkg-buildflags(1) export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND := -fopenmp -mtune=native -O3 -fPIC -flto=jobserver -flto-compression-level=9 -funroll-loops -DMKL_LP64 -DM_PI=3.1415926535897932384 -I/usr/include/mkl export DEB_CXXFLAGS_MAINT_APPEND := $(DEB_CFLAGS_MAINT_APPEND) export DEB_CPPFLAGS_MAINT_APPEND := $(DEB_CFLAGS_MAINT_APPEND) export DEB_FFLAGS_MAINT_APPEND := -fopenmp -mtune=native -O3 -fPIC -ffree-line-length-0 export DEB_FCFLAGS_MAINT_APPEND = $(DEB_FFLAGS_MAINT_APPEND) export DEB_LDFLAGS_MAINT_APPEND := -fPIC -Wl,--start-group -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -Wl,--end-group -lgomp -lpthread -lm -ldl # the last line is for compiling with IntelMKL override_dh_auto_configure: $(overridden_command) -- -DBUILD_TESTING=OFF -DJULIA_EXECUTABLE=/usr/bin/julia -DCMAKE_BUILD_TYPE=debug #(so, CMAKE_BUILD_TYPE only once and Debug, but what the heck where is the output…) -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #15 from Nikita Sirgienko --- (In reply to vialav from comment #14) > There is nothing useful in the output, when I log in into julia (btw, what > 'log in' means in this context? I simply [tried to] started the julia > session, which produced no output there): Your cmake command (below) set CMAKE_BUILD_TYPE twice (first as None) so Cantor not builded in debug mode. When Cantor will builded in debug mode, you should see a lot of output in console. Could you please rebuild Cantor? cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_BUILD_TYPE=Debian -DCMAKE_INSTALL_SYSCONFDIR=/etc -DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DBUILD_TESTING=OFF -DJULIA_EXECUTABLE=/usr/bin/julia -DCMAKE_BUILD_TYPE=debug .. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #14 from vialav --- I did everything as being told, and there is no difference in the end result… Usually I don't need to set JULIA_EXECUTABLE, as it is in the default path: -DJULIA_EXECUTABLE=/usr/bin/julia > Also, it's helpfull, if you will build debug cantor version and post Cantor > debug output here, when your tried to login into julia. There is nothing useful in the output, when I log in into julia (btw, what 'log in' means in this context? I simply [tried to] started the julia session, which produced no output there): $ cantor Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/16/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/22/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/24/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/32/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/48/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/64/" Invalid Context= "stock" line for icon theme: "/usr/share/icons/ubuntu-mono-dark/stock/128/" That it was indeed, the debug version, is that I've got the CantorTargets-debug.cmake file instead of CantorTargets-debin.cmake -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #13 from vialav --- Created attachment 120482 --> https://bugs.kde.org/attachment.cgi?id=120482=edit build log -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #12 from vialav --- Created attachment 120481 --> https://bugs.kde.org/attachment.cgi?id=120481=edit Calculating… -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 Nikita Sirgienko changed: What|Removed |Added Assignee|cantor-b...@kde.org |warqu...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #11 from vialav --- Thank you, I'll try it now and will be shortly back. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #10 from Nikita Sirgienko --- (In reply to Nikita Sirgienko from comment #9) > -DJULIA_EXECUTABLE=/mnt/Red/progs_for_cantor/julia-1.2.0-rc1/bin/julia > -DCMAKE_BUILD_TYPE=release .. This is actually release build and should be "-DCMAKE_BUILD_TYPE=debug", but I think, you got the idea. Also, it's helpfull, if you will build debug cantor version and post Cantor debug output here, when your tried to login into julia. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #9 from Nikita Sirgienko --- (In reply to vialav from comment #6) > Yes, I was rebuilding Cantor after each Julia headers upgrade, with no > specific manipulations. > > The version(s) of Julia I was using were simply the prepared receipt of: > https://packages.debian.org/src:julia > # list of files there > > adopted further for Julia v1.1.1 and v1.2.0-rc1 with a trivial version > uptick, but it didn't work even with v1.1.0 provided by Debian Do you sure, that cmake had found Julia version that you want? For example, it's my sequence of commands to build cantor (debug version) with julia v1.2.0-rc1 $ cd /tmp $ git clone https://github.com/KDE/cantor $ cd cantor $ mkdir build $ cd build $ cmake -DJULIA_EXECUTABLE=/mnt/Red/progs_for_cantor/julia-1.2.0-rc1/bin/julia -DCMAKE_BUILD_TYPE=release .. I actually see, that cmake found the needed Julia, because in cmake output I have this (see second line, version also mentioned): ``` -- Found LuaJIT: /usr/lib/x86_64-linux-gnu/libluajit-5.1.so -- Found Julia: /mnt/Red/progs_for_cantor/julia-1.2.0-rc1/lib/libjulia.so (found version "1.2.0") -- The following OPTIONAL packages have been found ``` $ make -j16 && sudo make install -j16 $ cantor -b julia Could you please check, that cmake output for your version has "found version 1.1.0"? -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #8 from vialav --- Nikita, I mistook my reverted patch for the direct one (I couldn't have compiled the said backend with the wrong one), sorry for not checking. So, true: >> Future Julia versions since v1.1.0 haven't `exception_in_transit` and have >> `previous_exception` It was https://phabricator.kde.org/D19549 **at the time** where there was 'a tarball' with the opposite (see it within the comments), which is why Ubuntu has made v18.12.3a, https://packages.ubuntu.com/src:cantor But, ok, let's see if: …we're both using: Cantor v19.07.70+git20190523 # master branch, merged into Applications/19.04 (the commit of May 23) …and may be I can have a second look at the way I've compiled Cantor. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #7 from Nikita Sirgienko --- (In reply to vialav from comment #5) > Hi, Nikita, > > I am puzzled… Are we both using: > > Cantor v19.07.70+git20190523 > # master branch, merged into Applications/19.04 (are you verifying the same?) > > Aren't there 'exception_in_transit' instead of 'previous_exception' in Julia > code base (headers)? (see it wrongly on: https://phabricator.kde.org/D19549) I have Julia v1.0.4, v1.1.0, v1.1.1, v1.2.0-rc1. Julia v1.0.4 has `exception_in_transit`: ``` 1998:/mnt/Red/progs_for_cantor/julia-1.0.4/include [17:52:10]$ grep 'previous_exception' -r * 1998:/mnt/Red/progs_for_cantor/julia-1.0.4/include [17:52:12]$ grep 'exception_in_transit' -r * julia/julia_threads.h:88:struct _jl_value_t *exception_in_transit; julia/julia.h:1703:if (((jl_get_ptls_states()->exception_in_transit==jl_stackovf_exception) && _resetstkoflw()) || 1) julia/julia.h:1912:#define jl_exception_in_transit (jl_get_ptls_states()->exception_in_transit) 1998:/mnt/Red/progs_for_cantor/julia-1.0.4/include [17:52:15]$ ``` Future Julia versions since v1.1.0 haven't `exception_in_transit` and have `previous_exception`: ``` 1998:/mnt/Red/progs_for_cantor/julia-1.1.0/include [17:47:04]$ grep 'exception_in_transit' -r * 1998:/mnt/Red/progs_for_cantor/julia-1.1.0/include [17:53:48]$ grep 'previous_exception' -r * julia/julia_threads.h:194:struct _jl_value_t *previous_exception; 1998:/mnt/Red/progs_for_cantor/julia-1.1.0/include [17:53:50]$ 1998:/mnt/Red/progs_for_cantor/julia-1.2.0-rc1/include/julia [17:42:48]$ grep 'previous_exception' -r * julia_threads.h:197:struct _jl_value_t *previous_exception; 1998:/mnt/Red/progs_for_cantor/julia-1.2.0-rc1/include/julia [17:43:11]$ grep 'exception_in_transit' -r * 1998:/mnt/Red/progs_for_cantor/julia-1.2.0-rc1/include/julia [17:57:38]$ 1998:/mnt/Red/progs_for_cantor/julia-1.1.1/include [17:53:45]$ grep 'exception_in_transit' -r * 1998:/mnt/Red/progs_for_cantor/julia-1.1.1/include [17:57:56]$ grep 'previous_exception' -r * julia/julia_threads.h:194:struct _jl_value_t *previous_exception; 1998:/mnt/Red/progs_for_cantor/julia-1.1.1/include [17:57:58]$ ``` As you see, I actually run grep utility in include directory and there isn't `exception_in_transit` in headers since v1.1.0 -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #6 from vialav --- Yes, I was rebuilding Cantor after each Julia headers upgrade, with no specific manipulations. The version(s) of Julia I was using were simply the prepared receipt of: https://packages.debian.org/src:julia # list of files there adopted further for Julia v1.1.1 and v1.2.0-rc1 with a trivial version uptick, but it didn't work even with v1.1.0 provided by Debian -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #5 from vialav --- Hi, Nikita, I am puzzled… Are we both using: Cantor v19.07.70+git20190523 # master branch, merged into Applications/19.04 (are you verifying the same?) Aren't there 'exception_in_transit' instead of 'previous_exception' in Julia code base (headers)? (see it wrongly on: https://phabricator.kde.org/D19549) What was you building environment? -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #4 from Nikita Sirgienko --- Created attachment 120474 --> https://bugs.kde.org/attachment.cgi?id=120474=edit Julia v1.2.0-rc1 succes login -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #3 from Nikita Sirgienko --- julia-1.2.0-rc1 aslo works fine and pass all tests (as well as version 1.1.1). -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 Nikita Sirgienko changed: What|Removed |Added CC||warqu...@gmail.com --- Comment #1 from Nikita Sirgienko --- Can't reproduce on Ubuntu 18.04.2 LTS on Julia v1.1.1 Do you change julia version by rebuilding Cantor with corresponding julia (via manipulating cmake JULIA_EXECUTABLE variable), or change path in Julia settings? It's important, because the path in settings not working and Cantor used system julia library (a peculiarity of embedding julia in application, I still search way to change this behaviour)? I had attached image of succes Julia's login below. -- You are receiving this mail because: You are watching all bug changes.
[cantor] [Bug 408179] Alternative initialisation? The properly patched Julia v1.1.0/v1.1.1/v1.2.0-rc1 backend still hungs forever
https://bugs.kde.org/show_bug.cgi?id=408179 --- Comment #2 from Nikita Sirgienko --- Created attachment 120473 --> https://bugs.kde.org/attachment.cgi?id=120473=edit Julia v1.1.1 succes login -- You are receiving this mail because: You are watching all bug changes.
