bugGNU Octave - Bugs: bug #64864, Segfault after 'cd...

 
 

bug #64864: Segfault after 'cd /path/to/somewhere' under Debian

Submitter:  Clara Hollomey <allthatsounds>
Submitted:  Mon 06 Nov 2023 12:06:50 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 7.3.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 24 Nov 2023 12:01:22 AM UTC, comment #15: 

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

Arun Giridhar <arungiridhar>
Group Member
Thu 23 Nov 2023 06:43:15 AM UTC, comment #14: 


comment #13:

> As I mentioned in comment 4, java-8 is fine, the newer ones are the problem.
>
> Dmitri.
> --
>


Ye I was referring to an old computer I have where I needed to set JAVA_HOME, since Arun had problems running Java at all.

This is the one I did the patch on and tested with:

octave:5> version -java
ans = Java 11.0.21+9-post-Debian-1 with Debian OpenJDK 64-Bit Server VM mixed mode, sharing


On Debian 13.

Petter <petter>
Wed 22 Nov 2023 10:51:11 PM UTC, comment #13: 

As I mentioned in comment 4, java-8 is fine, the newer ones are the problem.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 22 Nov 2023 10:48:18 PM UTC, comment #12: 

I had to specify 'JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64' on the ./configure line to make Java in Octave work when I had multiple javas installed. Maybe that is your issue?

I can run the test suite fine, but that's just n of 1.

Petter <petter>
Sat 18 Nov 2023 02:31:06 PM UTC, comment #11: 

It seems that calling `javachk ("jvm")` or `usejava ("jvm")` are enough for me to get a segfault, with or without the patch.

Java version:

$ java --version
openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35)
OpenJDK 64-Bit Server VM (build 21+35, mixed mode, sharing)


This is the case even for the stripped-down configure command `../configure --enable-java`.

Since I'm getting the crash in all cases, I cannot reliably test the patch. Could someone with a better JVM than mine test it pls?

Arun Giridhar <arungiridhar>
Group Member
Sat 18 Nov 2023 02:10:12 PM UTC, comment #10: 

Wait, now I'm getting the same crash even without the patch. I usually don't build with Java, so something is causing a problem. Digging deeper next.

Arun Giridhar <arungiridhar>
Group Member
Sat 18 Nov 2023 03:05:26 AM UTC, comment #9: 

Getting a crash with the patch on make check and make check-vm:


  libinterp/octave-value/ov-class.cc-tst .........................fatal: caught signal Segmentation fault -- stopping myself...
make[1]: *** [Makefile:3005: check-vm] Error 139


 libinterp/octave-value/ov-class.cc-tst .........................fatal: caught signal Segmentation fault -- stopping myself...
make[4]: *** [Makefile:3002: check-local] Error 139


Octave was built with

../configure --enable-std-pmr-polymorphic-allocator --enable-largefile --enable-year2038 --enable-threads=posix --enable-64 --enable-openmp --enable-readline --enable-fftw-threads --enable-java --enable-docs --disable-lib-visibility-flags --with-openssl=yes --with-qt=5


Arun Giridhar <arungiridhar>
Group Member
Fri 17 Nov 2023 11:42:18 PM UTC, comment #8: 

Reading #64735 again, it do seem octave-cli related, so I guess that would also be solved by the patch.

Petter <petter>
Thu 16 Nov 2023 10:20:43 PM UTC, comment #7: 


comment #6:

> @Petter, does the patch in comment #5 also resolve bug #60620 and bug #64735?


Maybe. I think it would solve #60620. #64735 I dunno.

I ran 'octave' instead of 'octave-cli' to see what thread the interpreter runs in, and it does not seem to be the primordial thread on my system.

However, Qt seems to run some sort of poll function QEventLoop() in the primordial thread, so in theory there could be issues there too, if the event loop calls some java code via Octave at some point. But I dunno what the event loop actually does.

Also, maybe earlier versions of Qt did things differently.

https://bugs.openjdk.org/browse/JDK-6316197

The general recommendation from Sun seemed to be to not attach the jvm to the primordial thread.

Petter <petter>
Thu 16 Nov 2023 07:39:26 PM UTC, comment #6: 

@Petter, does the patch in comment #5 also resolve bug #60620 and bug #64735?

Arun Giridhar <arungiridhar>
Group Member
Wed 15 Nov 2023 10:48:57 PM UTC, comment #5: 

I read up a bit and it seems like the problem is that the jvm is attached to the "primordial thread" (the original thread), which the jvm have a hard time finding the end of the stack in, to put its stack protection pages.

Using octave-cli:

> _init_java_; test eigs;


Segfaults, since the C stack goes into the jvm stack protection pages.

> test eigs; _init_java_; test eigs;


Does not segfault, since the protection pages are placed with an offset to the maximum extent of the C stack.

The reason octave-cli has this problem and not octave, is due to octave spawning a thread.

So I made a patch in which a thread is spawned in main() for the cli executable, which seems to solve the issue.

I also had a issue with openblas running (apart from the Java problem)

echo "pkg load ltfat; load vars;g = double(g); G=frsynmatrix(frame('dgt',g,a,M),length(g)); disp (a); (G*G')^(1/2); disp ('done')" | ./octave-cli


It was probably due to https://github.com/OpenMathLib/OpenBLAS/issues/3740 and a apt-get upgrade solved that for me.

Without the patch there is a segfault still.


(file #55331)

Petter <petter>
Wed 08 Nov 2023 04:28:04 AM UTC, comment #4: 

I can reproduce segfault with   java-latest-openjdk.x86_64

version -java
ans = Java 20.0.2+9 with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode, sharing

or java-11-openjdk.x86_64

octave:1> version -java
ans = Java 11.0.18+10-LTS with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode, sharing


but not with java-1.8.0-openjdk.x86_64.

version -java
ans = Java 1.8.0_362-b08 with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode


Looking at

$ java -XX:+PrintFlagsFinal -version | grep -i stack


I see that on java-1.8

intx CompilerThreadStackSize                   = 0                                   {pd product}


while on 11 and 20 it is 1024.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Tue 07 Nov 2023 11:24:11 PM UTC, comment #3: 

I can recreate the segfault with stock Octave 7.3.0 and also the dev top on my Debian 12 machine.

Setting the jvm stack with -Xss10 mitigates the segfault.

I think it is the same bug as this one:
https://savannah.gnu.org/bugs/?60620

Petter <petter>
Tue 07 Nov 2023 09:58:38 PM UTC, comment #2: 


> JAVA calls


I got some problems with the C stack after Java was used from Octave in some Debian system, in totally unrelated code like you describe.

Could you put a file "java.opts" in the folder
OCTAVE_HOME/share/octave/OCTAVE_VERSION/m/java/

with:

-Xss10m


in it and see if it solves the issue? It should set the JVM stack to 10mb.

Petter <petter>
Mon 06 Nov 2023 12:40:10 AM UTC, comment #1: 

I cannot reproduce this on Centos Stream 9 with current development version:

 octave:1> pkg load ltfat
warning: function /home/dima/.local/share/octave/api-v58/packages/ltfat-2.6.0/deprecated/normalize.m shadows a core library function
warning: called from
    ltfatstart at line 212 column 5
    /home/dima/.local/share/octave/api-v58/packages/ltfat-2.6.0/PKG_ADD at line 2 column 1
    load_packages_and_dependencies at line 56 column 5
    load_packages at line 53 column 3
    pkg at line 639 column 7

warning: function /home/dima/.local/share/octave/api-v58/packages/ltfat-2.6.0/thirdparty/misc/im2double.m shadows a core library function
warning: called from
    ltfatstart at line 212 column 5
    /home/dima/.local/share/octave/api-v58/packages/ltfat-2.6.0/PKG_ADD at line 2 column 1
    load_packages_and_dependencies at line 56 column 5
    load_packages at line 53 column 3
    pkg at line 639 column 7

octave:2> load var
var   vars
octave:2> load vars
octave:3> g = double(g);
octave:4> G=frsynmatrix(frame('dgt',g,a,M),length(g));
octave:5> (G*G')^(1/2);
octave:6> whos
Variables visible from the current scope:

variables in scope: top scope

  Attr   Name        Size                     Bytes  Class
  ====   ====        ====                     =====  =====
  c      G         144x256                   589824  double
         M           1x1                          8  double
         a           1x1                          8  double
  c      ans       144x144                   331776  double
         g         144x1                       1152  double

Total is 57746 elements using 922768 bytes

octave:7>


I suspect openblas to be the problem. Do you get the crash if you
LD_PRELOAD reference blas? Start octave as:


$ LD_PRELOAD=/usr/lib/libblas.so octave


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 06 Nov 2023 12:06:50 AM UTC, original submission:  

Under Debian, with Octave 7.3.0 without GUI,
running 'pkg load ltfat' caused segfaults when performing openblas matrix calculations (immediately) afterwards.
We could fix the issue for LTFAT by avoiding all 'cd /path/to/somewhere' commands during PKG_ADD.

Speculatively, it may be that 'cd' leads to failed JAVA calls that may in turn affect openblas.
Please see https://github.com/ltfat/ltfat/issues/182 for details.

Clara Hollomey <allthatsounds>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55331:  32682.patch added by petter (2KiB - text/x-patch)

 

Carbon-Copy List
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by petter (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by allthatsounds (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-11-18 arungiridhar Dependencies- Depends on bugs #64735
    2023-11-18 arungiridhar Dependencies- Depends on bugs #60620
    2023-11-15 petter Attached File- Added 32682.patch, #55331

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code