[Octave-bug-tracker] [bug #61911] testsuite segfaults on Debian armel

[Sébastien Villemot]

Follow-up Comment #4, bug #61911 (project octave):

[comment #3 commentaire #3 :]
> Question #1: Does RC1 pass on other 32-bit platforms or is it all 32-bit
CPUs which have an issue?

Yes, RC1 passes on other 32-bit platforms: armhf (ARM v7 with hardware float)
and i386 (x86)

> Question #2: Does ARM v5 pass with 64-bit builds?

I don’t think there is such a think as ARM v5 64-bit. But RC1 passes on ARM
v8 64-bit.

> 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’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).

The backtrace shows that it happens at libinterp/parse-tree/pt-idx.cc:123: the
pointer to be freed is invalid.

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).

I can try to extract more information as requested. In particular, is there an
easy procedure to build Octave with ASAN?

Alternatively, 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.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61911>

_______________________________________________
  Message posté via Savannah
  https://savannah.gnu.org/