octave crashes or exits when lapack error handler xerbla is called

Bug #1156575 reported by Walter Garcia-Fontes
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Octave
Unknown
Unknown
octave (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Octave crashed while using the function "fsolve"

ProblemType: Crash
DistroRelease: Ubuntu 13.04
Package: octave 3.6.4-1
ProcVersionSignature: Ubuntu 3.8.0-13.22-generic 3.8.3
Uname: Linux 3.8.0-13-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.9.1-0ubuntu1
Architecture: amd64
Date: Mon Mar 18 12:44:23 2013
ExecutablePath: /usr/bin/octave
InstallationDate: Installed on 2010-10-25 (874 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
MarkForUpload: True
ProcCmdline: octave
Signal: 6
SourcePackage: octave
StacktraceTop:
 raise () from /lib/x86_64-linux-gnu/libc.so.6
 abort () from /lib/x86_64-linux-gnu/libc.so.6
 ?? () from /lib/x86_64-linux-gnu/libc.so.6
 ?? () from /lib/x86_64-linux-gnu/libc.so.6
 std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
Title: octave crashed with SIGABRT in raise()
UpgradeStatus: Upgraded to raring on 2013-03-01 (17 days ago)
UserGroups: adm admin audio cdrom dialout lp lpadmin plugdev sambashare video www-data

Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :
information type: Private → Public
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f84b96a0860 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:199
 malloc_printerr (ptr=0x24ed360, str=0x7f84b96a0a28 "double free or corruption (fasttop)", action=3) at malloc.c:4902
 _int_free (av=<optimized out>, p=0x24ed350, have_lock=0) at malloc.c:3758
 _M_grab (__alloc1=..., this=<optimized out>, __alloc2=...) at /build/buildd/gcc-4.7-4.7.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:226
 _M_grab (__alloc2=..., __alloc1=..., this=<optimized out>) at /build/buildd/gcc-4.7-4.7.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:244

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in octave (Ubuntu):
importance: Undecided → Medium
summary: - octave crashed with SIGABRT in raise()
+ octave crashed with SIGABRT in __libc_message()
tags: removed: need-amd64-retrace
Revision history for this message
Mike Miller (mtmiller) wrote : Re: octave crashed with SIGABRT in __libc_message()

Thank you for taking the time to report this bug and helping to make Ubuntu better. We need some more information from you before we can start working on this bug.

First, is this bug reproducible on your system?

If so, please attach or paste the contents of the function "f" that was passed to fsolve when the crash occurred.

Also please include a list of installed Octave packages by running the command "pkg list" at the Octave interpreter prompt.

Changed in octave (Ubuntu):
status: New → Incomplete
Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

Here is the list of packages:

ackage Name | Version | Installation directory
-------------------+---------+-----------------------
            audio *| 1.1.4 | /usr/share/octave/packages/audio-1.1.4
        benchmark *| 1.1.1 | /usr/share/octave/packages/benchmark-1.1.1
              bim *| 1.1.1 | /usr/share/octave/packages/bim-1.1.1
   communications *| 1.1.1 | /usr/share/octave/packages/communications-1.1.1
          control *| 2.4.0 | /usr/share/octave/packages/control-2.4.0
   data-smoothing *| 1.3.0 | /usr/share/octave/packages/data-smoothing-1.3.0
        dataframe | 0.9.1 | /usr/share/octave/packages/dataframe-0.9.1
     econometrics *| 1.0.8 | /usr/share/octave/packages/econometrics-1.0.8
        financial *| 0.4.0 | /usr/share/octave/packages/financial-0.4.0
            fixed *| 0.7.10 | /usr/share/octave/packages/fixed-0.7.10
              fpl *| 1.3.3 | /usr/share/octave/packages/fpl-1.3.3
               ga *| 0.10.0 | /usr/share/octave/packages/ga-0.10.0
          general *| 1.3.2 | /usr/share/octave/packages/general-1.3.2
         geometry *| 1.6.0 | /usr/share/octave/packages/geometry-1.6.0
              gsl *| 1.0.8 | /usr/share/octave/packages/gsl-1.0.8
            image *| 2.0.0 | /usr/share/octave/packages/image-2.0.0
               io *| 1.0.19 | /usr/share/octave/packages/io-1.0.19
             java *| 1.2.8 | /usr/share/octave/packages/java-1.2.8
   linear-algebra *| 2.2.0 | /usr/share/octave/packages/linear-algebra-2.2.0
          mapping *| 1.0.7 | /usr/share/octave/packages/mapping-1.0.7
    miscellaneous *| 1.1.0 | /usr/share/octave/packages/miscellaneous-1.1.0
missing-functions *| 1.0.2 | /usr/share/octave/packages/missing-functions-1.0.2
              msh *| 1.0.6 | /usr/share/octave/packages/msh-1.0.6
              nan | 2.5.5 | /usr/share/octave/packages/nan-2.5.5
             nnet *| 0.1.13 | /usr/share/octave/packages/nnet-0.1.13

I will attach next a testcase program that crashes my octave sytem, reproducible each time.

Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

#!/usr/bin/octave
     # Simulation for girlshare paper

%cancel pager and warnings
more off
warning("off");

% load packages
pkg load all;

global Ei;
global Vi;
global lambda;
Ei= -0.2;
Vi= 2;
lambda= 0.7;

function y = f(x)
global Ei;
global Vi;
global lambda;

   y = zeros (3, 1);
   y(1) = quad(@(v) v * normpdf(v,x(2),x(3)) , x(1), inf) - lambda * Ei;
   y(2) = quad(@(v) v^2 .* normpdf(v,x(2),x(3)),x(1),inf) - lambda * (Vi + Ei^2);
   y(3) = quad(@(v) normpdf(v,x(2),x(3)),x(1),inf) - lambda;
endfunction

[x, fval, info] = fsolve(@f, [-1;0;2])

Ei= 1.4;
Vi= 0.01;
lambda= 0.33;

function y = f(x)
global Ei;
global Vi;
global lambda;

   y = zeros (3, 1);
   y(1) = quad(@(v) v * normpdf(v,x(2),x(3)) , x(1), inf) - lambda * Ei;
   y(2) = quad(@(v) v^2 .* normpdf(v,x(2),x(3)),x(1),inf) - lambda * (Vi + Ei^2);
   y(3) = quad(@(v) normpdf(v,x(2),x(3)),x(1),inf) - lambda;
endfunction

Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

With the first set of parameters "fsolve" runs fine, with the second one it crashes octave.

Revision history for this message
Mike Miller (mtmiller) wrote :

Thanks, I am able to reproduce this now with your provided script and with the set of packages you have listed.

I am also assuming you have the default Ubuntu configuration for ATLAS, BLAS, and LAPACK. Can you confirm that the crash no longer occurs if you run the following command:

$ sudo update-alternatives --set liblapack.so.3 /usr/lib/atlas-base/atlas/liblapack.so.3

Does your example script run successfully? Do you see the "ABNORMAL RETURN FROM DQAGI" messages? Does the result from fsolve look like you expect?

Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

I suppose I do have the default configuration for ATLAS, BLAS, and LAPACK since I don't know what these are and I haven't touched anything related to them.

After running the command you suggest my script runs OK and the results also look OK as far as I can tell.

Revision history for this message
Mike Miller (mtmiller) wrote :

To sum up, the crash in Octave is unfortunate and should be fixed, but the system of equations that you are feeding fsolve is a contributing factor. Your function f(x) is not well-defined over all values of x, for example

octave:1> x = [0;0;0];
octave:2> f(x)
 ABNORMAL RETURN FROM DQAGI
 ABNORMAL RETURN FROM DQAGI
 ABNORMAL RETURN FROM DQAGI
ans =

   NaN
   NaN
   NaN

With the second set of parameters, I can verify that the crash occurs as a NaN value is being passed into a LAPACK function that does not behave well when one of its arguments is a NaN.

So in addition to the fix I suggested above, you could also ensure your function returns real values for all reasonable input values to avoid passing bad arguments into the library routines used by Octave.

Do these suggestions resolve this issue for you?

Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

Thanks, yes we can close the bug, I will take care of the NaN values in my particular case, but shouldn't octave report some error instead of crashing if this happens?

Revision history for this message
Mike Miller (mtmiller) wrote :

I don't mean to close the bug, I just want to make sure the problem has a workaround that works for you.

As far as fixing this, I think there are really two bugs here:

1) An invalid value is being passed to an lapack routine, but I'm not sure if it's because your function is returning NaN under certain conditions or because of a bug in lapack. I see this with lapack version 3.4.2 (in Ubuntu 13.04) but not with version 3.4.1 (in 12.10). I will look more into this to see if it is worth reporting as a bug in lapack.

2) Octave already has a method for handling errors in the lapack routines like this one, but it is not working with the latest lapack library in Ubuntu 13.04. I've reported this to Octave upstream, but I'm not sure if anything can be done other than detect that lapack is built a certain way and that handling errors won't work as expected. Maybe better to turn this into a bug against the lapack packaging.

Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

Thanks again Mike, my routine does indeed produce NaN values under certain conditions, and for me the workaround has worked perfectly. If I can be of any help further in this bug please let me know.

Revision history for this message
Mike Miller (mtmiller) wrote :

Ok, I've confirmed that the same values are being passed in to both versions of lapack from Octave, one calls the internal error handler and one does not. This is due to a fix in lapack that the norm of any matrix containing a NaN is now NaN. This confirms that the new behavior is correct and it should be erroring out. Therefore (1) in my comment #14 is not a bug.

So the remaining bug is that Octave is no longer able to handle lapack errors due to a change in how the lapack package is built on Ubuntu. I'll rename this appropriately and follow up to see if anything can be done in either Octave or lapack or both.

Mike Miller (mtmiller)
summary: - octave crashed with SIGABRT in __libc_message()
+ octave crashes or exits when lapack error handler xerbla is called
Mike Miller (mtmiller)
Changed in octave (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Mike Miller (mtmiller) wrote :

Ok, I have confirmed that this bug is now fixed in the latest development version of Ubuntu - Saucy Salamander. The latest upload of the lapack library has fixed the problem such that Octave is now able to handle and report the error instead of crashing.

If you can upgrade your system to the development version of Ubuntu or wait until it is released in October, you should see this bug resolved. If you need a fix for the bug in previous versions of Ubuntu, please follow the instructions for "Requesting a Backport" at https://wiki.ubuntu.com/UbuntuBackports#Requesting_a_Backport

Changed in octave (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Walter Garcia-Fontes (walter-garcia) wrote :

Thanks for the info, I've been using the 13.10 for some weeks now.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.