Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

BUG: SegFault when using numpy with jnius

See original GitHub issue

I had a nasty SegFault issue with numpy+jnius in my program. And after much debugging I found that for some reason -> it was being caused if I used the linalg.inv() function with jnius imported. I am not sure where the issue exactly is - jnius or numpy? In jnius: https://github.com/kivy/pyjnius/issues/490 In jpype: https://github.com/jpype-project/jpype/issues/808

Reproducing code example:

I can reproduce this exactly with:

$ docker run --rm -it centos:7 /bin/bash
# yum install -y wget bzip2 which java-1.8.0-openjdk-devel
# wget https://repo.anaconda.com/miniconda/Miniconda3-4.7.12-Linux-x86_64.sh
# bash ./Miniconda3-4.7.12-Linux-x86_64.sh -b
# /root/miniconda3/bin/pip install pyjnius==1.2.1 numpy==1.17.4
# /root/miniconda3/bin/python
>>> import jnius
>>> import numpy as np
>>> tmp = np.linalg.inv(np.random.rand(24, 24))
Segmentation fault

Error message:

GDB Traceback for the SegFault:

(gdb) r
Starting program: /root/miniconda3/bin/python run.py
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 533.
Detaching after fork from child process 535.
Detaching after fork from child process 536.

Program received signal SIGSEGV, Segmentation fault.
0x00007f3026ee82b4 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.3.x86_64 java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.x86_64
(gdb) bt
#0  0x00007f3026ee82b4 in ?? ()
#1  0x0000000000000246 in ?? ()
#2  0x00007f3026ee8160 in ?? ()
#3  0x00007f303829a6f8 in Abstract_VM_Version::_reserve_for_allocation_prefetch ()
   from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/jre/lib/amd64/server/libjvm.so
#4  0x00007fff1187df20 in ?? ()
#5  0x00007f3037d804dd in VM_Version::get_processor_features() ()
   from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/jre/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

Numpy/Python version information:

Numpy - 1.17.4
Jnius - 1.2.1
Python - 3.7.4 / Anaconda 4.7.12
GCC - 7.3.0
Linux x86-64 - CentOS 7

Note: It is reproducible on

Anaconda 4.5.4 / Python 3.6.5 / GCC 7.2.0
CentOS7’s yum python3 package (3.6.8) / GCC 4.8.5

It is not reproducible on MacOS.

Issue Analytics

State:
Created 4 years ago
Comments:21 (7 by maintainers)

Top GitHub Comments

1reaction

martin-frbgcommented, Oct 19, 2022

Long time no java, but try setting _JAVA_OPTIONS or JAVA_TOOL_OPTIONS instead of your JAVA_OPTS. Btw which version of OpenBLAS are you using, I think I already made changes to the allocations in getrf&friends to play nicely with Java’s default stack constraint sometime in late 2020 ?

1reaction

martin-frbgcommented, Oct 19, 2022

Stack-size issues with Java have come up occasionally, and recent OpenBLAS requires less stack than it used to. However from my POV the easiest fix would seem to be to specify a larger stackframe in Java than its default 1 megabyte.