GNU OCTAVE X64 PROBLEMS SOFTWARE
11 Comparison with other similar software.6.1 Command and variable name completion.
GNU OCTAVE X64 PROBLEMS INSTALL
In particular, is there an easy procedure to build Octave with ASAN?Īlternatively, you can try to reproduce it yourself, if you have access to real ARM hardware it does not need to be as old as ARMv5: it can be a more recent ARM machine running any Linux flavour, in which you install a Debian sid armel chroot. I can try to extract more information as requested. Of course at this point it’s impossible to rule out a memory corruption happening before, or a problem in the toolchain (gcc, binutils, libc). The backtrace shows that it happens at libinterp/parse-tree/:123: the pointer to be freed is invalid. I’ve tried to reproduce the problem on a machine to which I have access, and I indeed got a segfault, but a bit later (in bug-35881/bug-35881.tst). > Question #3: Do you have interactive access to an ARM v5 32-bit without hardware float machine? It would be useful to know if just running octave and trying "test svds" causes a segfault or whether it is only when run as part of the test suite. I don’t think there is such a think as ARM v5 64-bit. > Question #2: Does ARM v5 pass with 64-bit builds? Yes, RC1 passes on other 32-bit platforms: armhf (ARM v7 with hardware float) and i386 (x86)
> Question #1: Does RC1 pass on other 32-bit platforms or is it all 32-bit CPUs which have an issue? Selected GCC installation: /usr/bin/./lib/gcc/arm-linux-gnueabi/11Ĭandidate multilib: multilib: A. Src/.libs/octave-cli: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, BuildID=4babeb227e9498c1cf1fcce2cba6d4d854b8abf9, for GNU/Linux 3.2.0, with debug_info, not strippedįound candidate GCC installation: /usr/bin/./lib/gcc/arm-linux-gnueabi/11 (I get dlmread FAIL and REGRESSION on aarch64 buid). It did not crash during make test though it had a few more FAILures. latomic was required, std=c++11 probably not. configure CC=clang CXX=clang++ CXXFLAGS="-std=c++11" LDFLAGS="-latomic" I have compiled rc1 on debian sid chroot armel (on Ubuntu 21.10 as a host) with clang pass 0/2Įrror: ignoring const execution_exception& while preparing to exit But at least there is no crash with that version.Īnd pretty much the same with gcc (./configure without any params): In the worst case, if we can’t find a solution, I will disable the testsuite at build time on Debian armel, but that’s not very satisfactory.Īlso note that there are test failures with Octave 6.4.0 on Debian armel (see ). But since this is an architecture officially supported by Debian, as the maintainer of the Debian package, I have no choice but to investigate issues there.
Note that I’m not personally interested in Octave on armel, which is an inadequate platform for number crunching (since it does not have hardware floats). If I had no issue with Clang, I would have been tempted to conclude that it’s a GCC bug, but things are not that simple. I don’t really know what to conclude from that. In both cases, I get memory bugs, though it is not the same one across compilers and it happens much earlier with GCC. I attach the results of exercising the testsuite with both compilers. I have recompiled Octave 7.0.90 on Debian sid armel, with ASAN, and with both GCC and Clang. libinterp/parse-tree/pt-select.h:279Īnd it is reproduciable 100% of few tries I had. #8 0xf61f357c in octave::tree_switch_command::accept(octave::tree_walker&). #7 0xf61629fc in octave::tree_evaluator::visit_switch_command(octave::tree_switch_command&). #6 0xf5a2628c in octave::tree_statement_list::accept(octave::tree_walker&). #5 0xf6161f14 in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&). #4 0xf61f7c80 in octave::tree_statement::accept(octave::tree_walker&). #3 0xf6161a28 in octave::tree_evaluator::visit_statement(octave::tree_statement&). /././src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:9986 #0 0xf770d6b8 in _interceptor_sigaltstack.
GNU OCTAVE X64 PROBLEMS PC
=459233=ERROR: AddressSanitizer: stack-use-after-scope on address 0xffb9db3c at pc 0xf770d6bc bp 0xffb9db14 sp 0xffb9d6e8 I got one almost right away at liboctave/array/-tst
0 kommentar(er)
