bugGNU Octave - Bugs: bug #60620, octave-cli crashes when...

 
 

bug #60620: octave-cli crashes when interacting with Java libraries

Submitter:  None
Submitted:  Mon 17 May 2021 10:07:18 AM UTC
   
 
Category:  Libraries Severity:  4 - Important
Priority:  7 - High Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Sergei Steshenko Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 6.2.0
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 21 Dec 2021 01:39:57 AM UTC, comment #43: 

comment #37:

> This bug has several workarounds listed, including increasing the stack space which can be done with pre-installed Octave binaries as well. Is this bug still a problem for the 7.1 release? What needs to happen before this bug can be closed?


Folks, before this bug is properly closed, I suggest to read and get duly and fully inspired by "Everything Is Broken" - https://medium.com/message/everything-is-broken-81e5f33a24e1 .

In this case in particular Octave is architecturally broken - Java should have never been a part of Octave executable. Instead, if/when Java is needed (Excel data parsing ?) it should be used via IPC.

Anonymous
Mon 20 Dec 2021 04:27:29 PM UTC, comment #42: 

Sorry posted the wrong file; It need to be "-Xss10m" not "-Xss:10m" but I forgot to commit that localy.

The value should probably be user configurable at runtime though? Or maybe set at build time to normal system stacksize?


(file #52539)

Petter <petter>
Sun 19 Dec 2021 02:28:04 PM UTC, comment #41: 

Maybe I should post my Java version too:
java --version
openjdk 11.0.13 2021-10-19
OpenJDK Runtime Environment (build 11.0.13+8-post-Debian-1)
OpenJDK 64-Bit Server VM (build 11.0.13+8-post-Debian-1, mixed mode, sharing)

I am using Debian 11, x64.

I found a 10yo discussion about this from someone that seemed to have the same problem:
https://stackoverflow.com/questions/7153177/jni-createjavavm-on-linux-destroys-stack

(The answers are clueless and thinks he had some other question)

Even older bug report from Sun:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6269555

The recommendation there is to get the stacksize value from "ulimits".

10mb would maybe not work on all platforms?

Petter <petter>
Sun 19 Dec 2021 01:22:26 PM UTC, comment #40: 


comment #39:

> Is there a particular reason you are using "XX:ThreadStackSize" over "Xss"?
> From https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html
> > Options that are specified with -XX are not stable and are subject to change without notice.


No reason really. I just took the first option that came up when I searched for "option Java thread stacksize". I'm not that much into Java, so I have no clue what I am doing :)

I guess increasing the thread stack size might be bad if users spawn a thread heavy Java webserver or something via Octave.

I tested with -Xss:10m and that solves the problem too, see attachment.

I also tested to define HAVE_BROKEN_PTHREAD_STACKSIZE, with no change in stacksize, and that did not solve the problem.

(file #52537)

Petter <petter>
Sun 19 Dec 2021 08:32:30 AM UTC, comment #39: 

Is there a particular reason you are using "XX:ThreadStackSize" over "Xss"?
From https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html

> Options that are specified with -XX are not stable and are subject to change without notice.

Markus Mützel <mmuetzel>
Group administrator
Sat 18 Dec 2021 08:05:55 PM UTC, comment #38: 

comment #37:

> This bug has several workarounds listed, including increasing the stack space which can be done with pre-installed Octave binaries as well. Is this bug still a problem for the 7.1 release? What needs to happen before this bug can be closed?


Yes I can't run the test suite on the trunk.

Steps to reproduce:

cd /home/petter/my_octave_clean/share/octave/8.0.0/etc/tests/libinterp/octave-value
test ov-java.cc-tst
%test eigs

% Testcase that overflows
A = toeplitz ([-2, 1, zeros(1, 8)]);
A = kron (A, eye (10)) + kron (eye (10), A);
opts.v0 = (1:100)';
opts.maxit = 1;
warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
d = eigs (A, 4, "sm", opts);
assert (d(4), NaN);


If I increase the Java thread stack size to 10MB the problem goes away,
see attached patch. I don't know what a reasonable number is, really.

(file #52532)

Petter <petter>
Mon 29 Nov 2021 01:25:47 PM UTC, comment #37: 

This bug has several workarounds listed, including increasing the stack space which can be done with pre-installed Octave binaries as well. Is this bug still a problem for the 7.1 release? What needs to happen before this bug can be closed?

Arun Giridhar <arungiridhar>
Group Member
Thu 12 Aug 2021 09:29:31 AM UTC, comment #36: 

As some points of reference:
https://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00262.html

> The default thread stack size is:
>  - glibc i386, x86_64    7.4 MB
>  - Tru64 5.1             5.2 MB
>  - Cygwin                1.8 MB
>  - Solaris 7..10           1 MB
>  - MacOS X 10.5          460 KB
>  - AIX 5                  98 KB
>  - OpenBSD 4.0            64 KB
>  - HP-UX 11               16 KB


https://docs.microsoft.com/en-us/cpp/build/reference/stack-stack-allocations?view=msvc-160

> For ARM, x86 and x64 machines, the default stack size is 1 MB.

(That is for MSVC. I'm not sure if it is the same for mingw.)


https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

> Xsssize
> Sets the thread stack size (in bytes). Append the letter k or K to indicate KB, m or M to indicate MB, g or G to indicate GB. The default value depends on the platform:
>
> Linux/ARM (32-bit): 320 KB
>
> Linux/i386 (32-bit): 320 KB
>
> Linux/x64 (64-bit): 1024 KB
>
> OS X (64-bit): 1024 KB
>
> Oracle Solaris/i386 (32-bit): 320 KB
>
> Oracle Solaris/x64 (64-bit): 1024 KB

https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html

> The default value depends on virtual memory.


So IIUC, on glibc x86_64, loading the JVM reduces the default stack size from 7.4 MiB to 1 MiB, or from 7.4 MiB to 320 kiB on glibc i386.
That seems to affect all (new?) threads, not only those of the JVM.

In bug #58641, we added a test and set default values for a different JVM switch for a similar issue. Should we do something like this here, too?

Markus Mützel <mmuetzel>
Group administrator
Wed 11 Aug 2021 06:07:11 PM UTC, comment #35: 

I could reproduce for the setup that Mike describes in comment #23.

The issue no longer appears if I increase the Java stack size (somewhat randomly) to 4 MiB:

system('echo -Xss4m >> $OCTAVE_JAVA_DIR/java.opts');


Maybe Java reduces the stack size for all threads when it is loaded - including those of OpenBLAS?

Markus Mützel <mmuetzel>
Group administrator
Wed 11 Aug 2021 04:33:14 PM UTC, comment #34: 

Hello, I found this bug report from last year. Could someone please summarize how a user can solve the problem? The thread lists these so far, so please check for accuracy:

1. Run Octave in GUI mode only not CLI mode.
2. If running in CLI mode, do not call "version -java".
3. Run self-built Octave with --disable-java, not precompiled.
4. Build libraries (?) with extra compiler flags related to stack protection? (Unclear).

Are there other workarounds?

Anonymous
Tue 25 May 2021 09:55:57 AM UTC, comment #33: 

FWIW, I can't provoke a crash on my Mageia-8 and Fedora-34 systems running the examples from comment #2 in Octave-7.0.0, either with GUI or CLI, the latter started in Konsole both as 'octave-cli' and 'octave --no-gui-libs':

# ========= Fedora 34: =========
>> system ("java --version")
openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment 18.9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.11+9, mixed mode, sharing)
ans = 0
>> version -java
ans = Java 1.8.0_292-b10 with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode
>> expfit(512, 0, 1, rand(1, 1024));
>> expfit(16, 0, 1, rand(1, 32));

# ========= Mageia 8: =========
>> system ("java --version")
openjdk 11.0.10-ea 2021-01-19 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.10-ea+1-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.10-ea+1-LTS, mixed mode, sharing)
ans = 0
>> version -java
ans = Java 11.0.10-ea+1-LTS with Mageia OpenJDK 64-Bit Server VM mixed mode, sharing
>> expfit(16, 0, 1, rand(1, 32));
>> expfit(512, 0, 1, rand(1, 1024));
>>


Philip Nienhuis <philipnienhuis>
Group Member
Tue 25 May 2021 03:22:21 AM UTC, comment #32: 

Can someone share if this behavior is specific only to some Java VMs or will it show up on any VM? Is there a difference between Open JDK's JVM and the Sun / Oracle JVM for this bug?

Anonymous
Tue 18 May 2021 05:47:37 PM UTC, comment #31: 

For Octave 7 on Linux from the CLI, configured and built with --disable-java, no crash:


octave:1> A = rand(512,512); b = rand(512,1); x = A\b;
octave:2> version -java
ans = no usable Java Runtime Environment (x86_64) found:
javaMethod: support for Java was unavailable or disabled when Octave was built
octave:3> A = rand(512,512); b = rand(512,1); x = A\b;
octave:4>


Anonymous
Tue 18 May 2021 11:00:29 AM UTC, comment #30: 

FTR, on Windows I see no crash with octave-cli and Java "loaded" (through loading the io package).

@OP (Sergei):
Good that this bug has been identified. I never thought of Java interaction, let alone a bug that happens only in octave-cli on Linux. Quite a creepy bug.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 18 May 2021 10:32:37 AM UTC, comment #29: 

The bug that Mike referenced in comment #18 might be bug #58641.
I don't recall the details. But I think there was some issue with some Java versions on some systems.

IIUC, the work-around that we implemented only applies if Octave starts its own Java VM. We didn't change anything for that bug for the case where Octave attaches to a Java VM that is already running.

I don't know much about Java and the JVM. Could it be that the CLI can connect to an already running Java VM that the GUI cannot detect? Maybe that JVM was started without the work-around.

Markus Mützel <mmuetzel>
Group administrator
Tue 18 May 2021 08:38:42 AM UTC, comment #28: 

Confirming the crash of comment #19 for openSUSE 15.2 using self-compiled Octave 6.2.1 and Octave 7 each with "octave-cli".

The version with "gui-libs" is unaffected from this crash.

This item seems unrelated to any Octave Forge package and as having Java on a Linux system is quite common, raising the priority.

Kai Torben Ohlhus <siko1056>
Group Member
Tue 18 May 2021 08:07:26 AM UTC, comment #27: 

comment #24:

> I actually cannot crash it with any combinations I tried.
> All Redhat's stuff compiled with -fstack-clash-protection -fcf-protection, I do not know if that makes a difference.
> (I did not use it to compile octave, but all libraries must have
> used those).
>
> Dmitri.
> --
>


So, maybe a developer should add these options to compiler flags, rebuild from source and check again whether Java crashes Octave ?

Anonymous
Tue 18 May 2021 08:04:00 AM UTC, comment #26: 

comment #19:

> Ok, I can also reproduce this in current versions of Octave, both version 6.2.0 and the version 7 development branch, if and only if running as 'octave-cli' (or equivalently with '--no-gui-libs').
>
> It's also possible to reproduce this in any of these versions of Octave without the optim package, so this can be separated from the expfit function specifically.
>
> I also get an error message printed directly by the Java runtime to the console on my main Debian development system:
>


> >> A = rand (512, 512);
> >> x = rand (512, 1);
> >> y = A \ x;
> >> version -java
> ans = Java 11.0.11-ea+4-post-Debian-1 with Debian OpenJDK 64-Bit Server VM mixed mode, sharing
> >> y = A \ x;
> An irrecoverable stack overflow has occurred.
> Please check if any of your loaded .so files has enabled executable stack (see man page execstack(8))
> fatal: caught signal Segmentation fault -- stopping myself...
> Segmentation fault (core dumped)


I think this discovery justifies changing the bug status to confirmed.

Anonymous
Tue 18 May 2021 08:01:13 AM UTC, comment #25: 

Now that it has been established that the bug has nothing to do with either 'optim'or 'expfit', but rather has everything to do with Octave in conjunction with Java. I suggest to change '[octave forge]' in the bug description to [octave] or whatever the appropriate category is.

Anonymous
Tue 18 May 2021 02:44:27 AM UTC, comment #24: 

I actually cannot crash it with any combinations I tried.
All Redhat's stuff compiled with -fstack-clash-protection -fcf-protection, I do not know if that makes a difference.
(I did not use it to compile octave, but all libraries must have
used those).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 18 May 2021 02:10:40 AM UTC, comment #23: 

Same, works fine for me with OpenBLAS with USE_OPENMP=1 or with USE_THREAD=0, crash occurs for me only with octave-cli, with Java loaded, and with OpenBLAS using pthreads. Also works with OMP_NUM_THREADS=1 in the environment.

Mike Miller <mtmiller>
Group Member
Tue 18 May 2021 01:48:33 AM UTC, comment #22: 

Also works fine with 7.0.0 on i9-9880 (with current dev java)
again with omp blas:

./run-octave --no-gui-libs -q -f
octave:1> version
ans = 7.0.0
octave:2> A=rand(512,512);
octave:3> x=rand(512,1);
octave:4> y = A\x ;
octave:5> version -java
ans = Java 16.0.1+9 with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode, sharing
octave:6> y = A\x ;
octave:7> version -blas
ans = FlexiBLAS Version 3.0.4
OpenBLAS (config: OpenBLAS 0.3.15 DYNAMIC_ARCH NO_AFFINITY USE_OPENMP Haswell MAX_THREADS=128)
octave:8> _octave_config_info_ ("hg_id")
ans = b36e83cdbf05
octave:9>

Dmitri.
--
 

Dmitri A. Sergatskov <dasergatskov>
Tue 18 May 2021 12:47:31 AM UTC, comment #21: 

I cannot reproduce it with 6.2.1 linked with openblas-omp library.

octave-cli -q -f
octave:1> A = rand (512, 512);
octave:2>  x = rand (512, 1);
octave:3> version
ans = 6.2.1
octave:4> y = A \ x;
octave:5> version -java
ans = Java 1.8.0_292-b10 with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode
octave:6> y = A \ x;
octave:7> version -java
ans = Java 1.8.0_292-b10 with Red Hat, Inc. OpenJDK 64-Bit Server VM mixed mode
octave:8> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.15 DYNAMIC_ARCH NO_AFFINITY USE_OPENMP Zen MAX_THREADS=128)

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 18 May 2021 12:24:44 AM UTC, comment #20: 

I just updated my Ubuntu installation from 20.10 to 21.04. I still have no error with the Ubuntu-installed octave (6.1.1 now), but have an error with my octave-cli (7.0.0, hg id: f6a8f103786e) which I had compiled and installed locally from development sources -- possibly because it is linked against a previous Java library version?

Nir Krakauer <nir_krakauer>
Mon 17 May 2021 11:53:46 PM UTC, comment #19: 

Ok, I can also reproduce this in current versions of Octave, both version 6.2.0 and the version 7 development branch, if and only if running as 'octave-cli' (or equivalently with '--no-gui-libs').

It's also possible to reproduce this in any of these versions of Octave without the optim package, so this can be separated from the expfit function specifically.

I also get an error message printed directly by the Java runtime to the console on my main Debian development system:


>> A = rand (512, 512);
>> x = rand (512, 1);
>> y = A \ x;
>> version -java
ans = Java 11.0.11-ea+4-post-Debian-1 with Debian OpenJDK 64-Bit Server VM mixed mode, sharing
>> y = A \ x;
An irrecoverable stack overflow has occurred.
Please check if any of your loaded .so files has enabled executable stack (see man page execstack(8))
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)


Mike Miller <mtmiller>
Group Member
Mon 17 May 2021 10:40:17 PM UTC, comment #18: 

Unfortunately, I don't think there is a way to unload Java from a running Octave instance once it's loaded.

There are numerous workarounds if you are not actually interested in any of the Java functions provided by the io package (which is an indirect dependency of the optim package).

One, you could fully uninstall the io package if you don't need it, and install the optim and statistics packages with the '-nodeps' option. However, I can't say for sure which particular functions may not work because of some missing io package function.

Another option, if you don't use Java at all on your system, is to apt remove all openjdk* packages. The Ubuntu repository version of Octave will still install without them, they are pulled in only as a Recommends dependency.

And as far as fixing the underlying bug, I'm sorry that I don't know or remember any further details about Java, I try to forget most things about Java. I think there may have been some problem with the way Java allocates stack space for dozens of background threads when the JVM starts up, and maybe there was a bug in some version of Java, or maybe some configuration change was made in later version of Java or Octave to limit that?

Mike Miller <mtmiller>
Group Member
Mon 17 May 2021 10:25:32 PM UTC, comment #17: 

Yes, it is Java which is causing the segfault:

"
octave:1> version -java
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "org.octave.OctClassLoader"). To use archived non-system classes, this property must be not be set
ans = Java 11.0.11+9-Ubuntu-0ubuntu2.18.04 with Ubuntu OpenJDK 64-Bit Server VM mixed mode, sharing
octave:2> load('-binary', 'foo.bin', 'foo')
octave:3> s = -foo.one\foo.two
Segmentation fault (core dumped)
".

I.e. if I first load Java and then try to perform the operation on saved data ('s = -foo.one\foo.two'), segfault occurs.

Without Java it doesn't occur.

Anonymous
Mon 17 May 2021 10:18:39 PM UTC, comment #16: 

Is there a way to unload Java ?
...
Actually, I need only 'expfit', so I can just use the .m file. But OTOH I might need other packages - like 'signal', so can it be that Java will still be pulled in ?
...
Many thanks for confirming the bug.

comment #15:

> I can reproduce this in a Ubuntu 18.04 virtual machine with the stock installed Octave 4.2.2 and the optim package installed from Forge.
>
> The segmentation fault appears to arise only when the Java runtime is loaded into Octave.
>
> This works just fine:
>


> addpath ~/octave/optim-1.6.1
> expfit (512, 0, 1, rand (1, 1024))


>
> But this is enough to reproduce the segmentation fault:
>


> addpath ~/octave/optim-1.6.1
> version -java
> expfit (512, 0, 1, rand (1, 1024))


>
> IIRC there have been problems reported before about memory problems when Java has been loaded.

Anonymous
Mon 17 May 2021 10:09:54 PM UTC, comment #15: 

I can reproduce this in a Ubuntu 18.04 virtual machine with the stock installed Octave 4.2.2 and the optim package installed from Forge.

The segmentation fault appears to arise only when the Java runtime is loaded into Octave.

This works just fine:


addpath ~/octave/optim-1.6.1
expfit (512, 0, 1, rand (1, 1024))


But this is enough to reproduce the segmentation fault:


addpath ~/octave/optim-1.6.1
version -java
expfit (512, 0, 1, rand (1, 1024))


IIRC there have been problems reported before about memory problems when Java has been loaded.

Mike Miller <mtmiller>
Group Member
Mon 17 May 2021 10:06:39 PM UTC, comment #14: 

On upgrading Octave.

I can pretty easily install octave-6.2.0 from flathub: https://www.flathub.org/apps/details/org.octave.Octave .

But unfortunately installing the packages requires installation of Octave development libraries, and I do not know how to do this when Octave is installed via flatpak. Or maybe the development libraries are installed with Octave automatically ?

Anonymous
Mon 17 May 2021 09:58:00 PM UTC, comment #13: 

And I have just changed text save format to binary to avoid any kind of rounding errors - though in reality there is still the issue of x86 internal 80 bit register representation vs 64 bit representation.

The behavior is still the same - there is no segfault with saved in binary form data.

Anonymous
Mon 17 May 2021 09:50:52 PM UTC, comment #12: 

I have modified 'expfit.m' this way - the bottom line is the offending one:

"
foo.one = A(:,1:deg);
foo.two = A(:,deg+1);
output_precision(25);
save_precision(25);
save('-text', 'foo.txt', 'foo');
s = - A(:,1:deg) \ A(:,deg+1);
".
As expected, the segfault is still present.

After the segfault the offending data is found in 'foo.txt' file.

After the segfault I invoke Octave again and from prompt do:

"
octave:13> load('-text', 'foo.txt', 'foo')
octave:14> s = - foo.one\foo.two
s =

   5.943788696566891793793275e-01
   6.243336229322766772753539e-01
   4.071329687950496767356867e-01
   4.019410952178621987407325e-01
  -2.517268467102328211026929e-01
  -7.948153211805004669798791e-01
  -7.127222427414680039348127e-01
  -1.457716297133185845424919e+00
  -1.518863854985087247229103e+00
  -7.496244257374140573801924e-01
  -1.041980051013670305337655e+00
  -4.580327435624297338634392e-01
   2.453953542006280796883289e-01
   7.360050855365433131183295e-01
   1.825649089808825786818147e+00
   7.020672768678591912916431e-01
".

I.e. even though the data is supposedly the same that caused segfault, when saved and then loaded it doesn't cause segfault.

I do not know how to explain this. Rounding errors slightly changing data and thus eliminating segfault ? Some parser error causing the offending 's = - A(:,1:deg) \ A(:,deg+1);' line to do something else ?

Anonymous
Mon 17 May 2021 09:20:11 PM UTC, comment #11: 

@comment #2:
Sorry I overlooked the 'y = rand(1, 1024)' line.

With that issue solved both examples in comment #2 work fine in Octave-7.0.0 and optim-1.6.1 (Mageia-8 Linux). That indicates that optim-1.6.1 is probably fine and your older Octave version is a more likely candidate to be at fault. Or maybe it's an unfortunate poisonous mix of exactly those two.

The optim package file log shows that expfit.m hasn't been touched since 2012 and I expect the core functions 'hankel' and 'roots' called by expfit.m haven't seen much change either lately apart from cosmetics like copyright updates. Add in the posts by Nir and Doug and I can only conclude that the issue is something in your Linux installation - Octave-4.2.2, numerical system libraries, whatever; but probably not optim-1.6.1.

Although it's a hassle for you (I can understand), I strongly advise to upgrade Octave to the latest version (or at least 5.2.0). If you do, please report back if it solved the issue.

I won't close this report (yet) but I'll set status to "works for me".

Philip Nienhuis <philipnienhuis>
Group Member
Mon 17 May 2021 09:11:46 PM UTC, comment #10: 

I have:
 optim *|   1.6.1 | /home/doug/octave/optim-1.6.1

Doug Stewart <dastew>
Mon 17 May 2021 09:04:36 PM UTC, comment #9: 

I've added a number of checkpoints to source code of 'expfit.m'. The piece of code of interest:

"
fprintf(stderr, "expfit CHECKPOINT 1\n");
% Solve for polynomial coefficients
A = hankel( y(1:N-deg),y(N-deg:N) );
fprintf(stderr, "expfit CHECKPOINT 2\n");
s = - A(:,1:deg) \ A(:,deg+1);
fprintf(stderr, "expfit CHECKPOINT 3\n");
".

This is what I get during execution:
"
octave:2> expfit(16, 0, 1, rand(1, 32))
expfit CHECKPOINT 1
expfit CHECKPOINT 2
Segmentation fault (core dumped)
".

So the original code line producing segfault is:

"
s = - A(:,1:deg) \ A(:,deg+1);
".

IMO it's some kind of problem with underlying linear algebra library.

Anonymous
Mon 17 May 2021 08:46:02 PM UTC, comment #8: 

'help expfit' states among other things:

"
The fit is very sensitive to the number of data points.
 It doesn't perform very well for small data sets.
 Theoretically, you need at least 2*deg data points
"
- pay special attention to "Theoretically, you need at least 2*deg data points". In my case segfault occurs at exactly "2*deg data points" - don't know whether it's important - maybe some matrix becomes ill-conditioned as a result and this causes segfault.

Anonymous
Mon 17 May 2021 08:41:19 PM UTC, comment #7: 

Some of the responders report that expfit works fine as part of optim-1.6.0.

Please note that I am using optim-1.6.1 - not optim-1.6.0. I.e. this may be a regression introduced in optim-1.6.1.

Anonymous
Mon 17 May 2021 08:36:09 PM UTC, comment #6: 

expfit works fine for me also.

Doug Stewart <dastew>
Mon 17 May 2021 08:24:46 PM UTC, comment #5: 

comment #4:

> I don't get an error with either of your examples, using Octave 5.2.0 and optim 1.6.0, both installed through Ubuntu.


My Ubuntu:

"
uname -a
Linux sergei-dt 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
".

And I have provided 3 examples which segfault.

The packages were installed from scratch from forge.

Anonymous
Mon 17 May 2021 08:12:28 PM UTC, comment #4: 

I don't get an error with either of your examples, using Octave 5.2.0 and optim 1.6.0, both installed through Ubuntu.

Nir Krakauer <nir_krakauer>
Mon 17 May 2021 07:46:24 PM UTC, comment #3: 

According to my observations the segfault occurs when 'deg' (per 'help expfit') is exactly half of length(y), and the last one-liner demonstrating the bug in my previous comment (which is

"
expfit(16, 0, 1, rand(1, 32))
"

) demonstrates minimum required power of 2 length(y) - which is 32.

Anonymous
Mon 17 May 2021 07:30:32 PM UTC, comment #2: 

comment #1:

> Can you show or upload the contents of 4th input arg y?


The contents are given by the following line in the original screen session:

"
octave:2> y = rand(1, 1024);
".

Or here is a one-liner:

"
octave:36> expfit(512, 0, 1, rand(1, 1024))
Segmentation fault (core dumped)
".

And another one-liner - much smaller dataset:

"
octave:5> expfit(16, 0, 1, rand(1, 32))
Segmentation fault (core dumped)
"

> I tried with dev Octave (7.0.0) but that just complained about "error: 'y' undefined ..."
>


Please see the above.

> BTW Octave-4.2.2 is old and unsupported, could you upgrade to v. 6.2.0 and try again?


This would mean a lot of hassle for me, and I suspect the problem is within the package which was built using the '-forge' option, so it's probably the newest or the problem is within a linear algebra library.


Anonymous
Mon 17 May 2021 06:27:04 PM UTC, comment #1: 

Can you show or upload the contents of 4th input arg y?

I tried with dev Octave (7.0.0) but that just complained about "error: 'y' undefined ..."

BTW Octave-4.2.2 is old and unsupported, could you upgrade to v. 6.2.0 and try again?

Philip Nienhuis <philipnienhuis>
Group Member
Mon 17 May 2021 10:07:18 AM UTC, original submission:  

Please see the following screen session:

octave:1> pkg load optim
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "org.octave.OctClassLoader"). To use archived non-system classes, this property must be not be set
octave:2> y = rand(1, 1024);
octave:3> version
ans = 4.2.2
octave:4> pkg describe optim
---
Package name:
        optim
Version:
        1.6.1
Short description:
        Non-linear optimization toolkit.
Status:
        Loaded
octave:5> expfit(512, 0, 1, y)
Segmentation fault (core dumped)

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Carbon-Copy List
  • -email is unavailable- added by petter (Updated the item)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by nir_krakauer (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by None (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 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-11-18 arungiridhar Dependencies- bugs #64864 is dependent
    2023-10-03 arungiridhar Dependencies- bugs #64735 is dependent
    2021-12-20 petter Attached File- Added set_java_stacksize_to_10MB_3.patch, #52539
    2021-12-19 petter Attached File- Added set_java_stacksize_to_10MB_2.patch, #52537
    2021-12-18 petter Attached File- Added set_java_stacksize_to_10MB.patch, #52532
    2021-05-18 siko1056 CategoryOctave Package Libraries
        Severity3 - Normal 4 - Important
        Priority5 - Normal 7 - High
        Item GroupNone Segfault, Bus Error, etc.
        StatusWorks For Me Confirmed
        Release4.2.2 6.2.0
        Summary[octave forge] (optim) 'expfit' function from optim-1.6.1 package terminates with segmentation fault octave-cli crashes when interacting with Java libraries
    2021-05-17 philipnienhuis StatusNeed Info Works For Me
    2021-05-17 philipnienhuis StatusNone Need Info
        Carbon-Copy- Added philipnienhuis
    2021-05-17 siko1056 Summary'expfit' function from optim-1.6.1 package terminates with segmentation fault [octave forge] (optim) 'expfit' function from optim-1.6.1 package terminates with segmentation fault

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code