[Octave-bug-tracker] [bug #64864] Segfault after 'cd /path/to/somewhere' under Debian

[Arun Giridhar]

Follow-up Comment #15, bug #64864 (project octave):

This was hairy, not because of the patch or the bug, but because of having to
manage Java.

1. I installed `jdk8-openjdk`, `jdk11-openjdk`, and `jdk17-openjdk`. I
exported JAVA_HOME to each location in turn for each of these tests, usually
with a fresh shell terminal. I was able to get make check and check-vm to work
with Java 8, but not with 11 or 17. BUT after running many of the tests below,
even Java 8 stopped working on the versions where it had worked before.

2. I had trouble installing ltfat because it kept complaining about the
polymorphic memory allocator. I enable that option in my Octave build but
ltfat is built with `-std=gnu++11` so that was not compatible. Eventually I
removed that gnu++11 from the relevant ltfat Makefile, repackaged it, and this
time it installed properly. (@Clara, please consider if removing that
specification from ltfat's build setting will be acceptable.)

3. Running this command gave no errors when Octave is built with
`--disable-java`:


pkg load ltfat; load vars; g = double(g);
G=frsynmatrix(frame('dgt',g,a,M),length(g)); (G*G')^(1/2);


4. Running the same command when Octave is built with `--enable-java` also
works with no errors with Java 8. For all other Java versions, the command
crashes, and running `make check` and `make check-vm` both crash. Even
`version -java` crashes:

octave:1> version -java
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)


After a long series of the above tests, on independent source and build trees,
I found that Java had stopped working with Octave throughout even with Java
8.

I also tried Petter's patch, but now it consistently crashes for all versions.
I don't think it's because of the patch, but because something about Java is
persistent when it should not be.

I will have to try again tomorrow, maybe from clean Octave clones. This is a
messy situation where the path order matters (i.e., testing X, undoing X, then
testing Y, gives a different result from testing only Y even with parallel
build directories and/or source directories).


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/