bugGNU Octave - Bugs: bug #41699, imformats causes a segmentation...

 
 

bug #41699: imformats causes a segmentation fault

Submitted by:  Ian Journeaux <ijourneaux>
Submitted on:  Tue 25 Feb 2014 10:17:16 PM UTC  
 
Category:  Octave Function Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  ijourneaux Open/Closed:  Closed
Release:  4.0.0 Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 12 May 2016 10:52:37 PM UTC, comment #124: 

Oops, I actually tested

test imread
clear all
test imread

Not "close all".

John W. Eaton <jwe>
Project Administrator
Thu 12 May 2016 10:51:11 PM UTC, comment #123: 

I have also built a Windows installer from the latest stable sources and I no longer see a segfault when repeatedly running

test imread
close all
test imread

so my hope is that this problem really is finally fixed.

John W. Eaton <jwe>
Project Administrator
Thu 12 May 2016 04:23:19 PM UTC, comment #122: 

Finally, finally, closing this report.

Rik <rik5>
Project Administrator
Sat 07 May 2016 07:40:28 PM UTC, comment #121: 

Using last changeset,

test imaread; clear all; test imread

does not crash, as it used to be in my build (comment #93).

Congratulations!

Avinoam Kalma <avinoam>
Project Member
Fri 06 May 2016 09:14:24 PM UTC, comment #120: 

I checked in separate changesets on stable and default, then merged stable to default.

http://hg.savannah.gnu.org/hgweb/octave/rev/6586202b3a87
http://hg.savannah.gnu.org/hgweb/octave/rev/44f7664689f2

John W. Eaton <jwe>
Project Administrator
Fri 06 May 2016 08:27:12 PM UTC, comment #119: 

Same here.  I'll check in a changeset.

I made my change on default.

I suppose I'll do the same on stable.  I think the changeset will be substantially different due to changes in the build system, so I'll just do that separately.

John W. Eaton <jwe>
Project Administrator
Fri 06 May 2016 08:21:10 PM UTC, comment #118: 

I just did a quick hack and building the functions directly into Octave works for the examples in this report, and 'make check' also passes.

Rik <rik5>
Project Administrator
Fri 06 May 2016 07:31:33 PM UTC, comment #117: 

OK, I can duplicate it also.

After installing debugging symbols for libtiff, I see the following traceback:

(gdb) where
#0  0x00007fac5856d600 in ?? () from /usr/lib/libGraphicsMagick-Q16.so.3
#1  0x00007fac5879161f in ?? () from /usr/lib/libGraphicsMagick-Q16.so.3
#2  0x00007fac5918e0b9 in TIFFDefaultDirectory (tif=tif@entry=0x7fac4850b6e0)
    at tif_dir.c:1340

That line in tif_dir.c appears to be

        if (_TIFFextender)
                (*_TIFFextender)(tif);

and _TIFFextender is global data.  So, my guess is something is not being initialized properly when libtiff is reloaded.  It also seems like potential trouble to have libtiff linked with a .oct file (by way of the GraphicsMagick library) and to also be loading a separate tiff library as a plugin for Qt.  Though I don't know for sure what the problem is, it is suspicious that removing the libqtiff.so file from the Qt plugins directory avoids the problem.

I guess I'll try making _magick_read_ a built-in function so that the GraphicsMagick library is just linked with Octave so it can't be unloaded.  If that solves the problem then maybe it's the best solution for now.  This issue has already consumed far too much time.

John W. Eaton <jwe>
Project Administrator
Fri 06 May 2016 05:48:39 PM UTC, comment #116: 

Good news / bad news.  I can now reproduce this error on Linux with the development branch.  That should make it easier to debug.  But, it really sucks that the bug is now multiple places.

Either of the two test cases fail in default, 4.0.2, and 4.0.1 for me now.  Changing tho Operating System to "Any".

Rik <rik5>
Project Administrator
Thu 05 May 2016 08:56:18 PM UTC, comment #115: 

I think we set the plugins path so that Qt image functions could handle various formats that aren't built-in to Qt by default.  Since we all Octave (and the Qt libraries) to be installed wherever, the compiled-in plugin path is wrong.

So, something about the qtiff library conflicts with GraphicsMagick in some way?

Maybe the best solution IS to just link graphicsMagick directly with Octave so that it can't be unloaded...

John W. Eaton <jwe>
Project Administrator
Thu 05 May 2016 12:48:08 AM UTC, comment #114: 

I vaguely recall something about Qt not looking in the right spot for plugins or maybe translations? when run via the tarball distro of mxe-octave.

The installer version creates a qt.conf file in the bin directory that sets the path for translations, and probally could also for plugins if needed (and if that worked) - but is only created currently in the installer

John Donoghue <lostbard>
Project Member
Wed 04 May 2016 10:03:28 PM UTC, comment #113: 

Comment #112 is confirmed.

There is definitely something odd going on with the QT_PLUGIN_PATH.  Does anyone remember why we have this environment variable?  The log in MXE repo says

changeset:   3909:586b26b09042
user:        John W. Eaton <jwe@octave.org>
date:        Fri Apr 17 14:53:00 2015 -0400
files:       installer-files/octave.vbs
description:
set QT_PLUGIN_PATH in octave.vbs

Tests:

1) Comment out QT_PLUGIN_PATH in octave.vbs.  WORKS
2) As above, use setenv (QT_PLUGIN_PATH) from within Octave.  WORKS
3) Restore QT_PLUGIN_PATH in octave.vbs.  Remove imageformats/ directory from the QT_PLUGIN_PATH dir.  WORKS
4) Restore imageformats/ directory.  Remove only qtiff4.dll.  WORKS

Rik <rik5>
Project Administrator
Wed 04 May 2016 08:58:30 PM UTC, comment #112: 

ok - works for me on win 10 as per comment #10.

Interestingly, If I leave the shortcuts to call the vbs script (and keep the startin to %USERPROFILE%) and instead change the vbs script to call octave.exe instead of octave-gui.exe and comment out the setting of QT_PLUGIN_PATH, it also appears to work without crashing for me

John Donoghue <lostbard>
Project Member
Wed 04 May 2016 06:00:20 PM UTC, comment #111: 

I've added bug #40689 as a dependency.

Rik <rik5>
Project Administrator
Wed 04 May 2016 05:50:40 PM UTC, comment #110: 

I've added bug #41074 as a dependency.  This was the original report that motivated the use of a vbs file.  Basically, we'll have a minimized command window in the taskbar if we change the shortcut not to use the vbs file.

@John: You want to change to running octave.exe --force-gui directly, rather than just octave-gui.exe.  I also changed my desktop shortcut to start in the $OCTAVE/bin directory.  With these changes I can run any of the problem code in this bug report repeatedly on a Windows XP VM.

@jwe: Running your test code with 4.0.2 produces this for me

>> imwrite (randi (255, 100, 100), "foo.tif");
>> clear all
>> imwrite (randi (255, 100, 100), "foo.tif");
warning: your version of GraphicsMagick limits images to 8 bits per pixel
warning: called from
    __imwrite__ at line 201 column 3
    imwrite at line 111 column 5

What may be significant is the warning.  Normally the code just segfaults so it is possible that what is happening is that the warning/exception handling mechanism is creating problems.  Or it could be a red herring.

Rik <rik5>
Project Administrator
Wed 04 May 2016 05:33:36 PM UTC, comment #109: 

On win10, using the official 4.0.2 installed version,

running from octave.vbs, at times 'test imread, clear all, test imread' will crash, at other times it will  stop responding somewhere within the second test imread (but not crash)

Pressing ctrl-c, or attempting to close the window then no longer works.

Running octave-gui.exe directly so far hasn't crashed, however stop responding somewhere within the second test imread.

John Donoghue <lostbard>
Project Member
Wed 04 May 2016 04:38:25 PM UTC, comment #108: 

Using Octave 4.0.2:

If I run octave-gui.exe directly, then Octave's EXEC_PATH and PATH (as returned by getenv) both contain Octave's $bindir.

The value of TERM as returned by getenv is cygwin, same as is set in the VBS file.

The only things that I see that are different are that the value of QT_PLUGIN_PATH is not set in the environment and the console is displayed temporarily before it is hidden.

I think we can export the QT_PLUGIN_PATH directly from Octave or a startup script.

So maybe we should just eliminate the VBS script?

John W. Eaton <jwe>
Project Administrator
Wed 04 May 2016 03:45:37 PM UTC, comment #107: 

The VBS script also sets up some things like the exec path and the TERM environment variable.  Can we do all of those things in the Octave binary itself?  Is there a way to hide the console as well?  I don't think we can avoid having a console (yet) because of the way the terminal input current works on Windows systems by mirroring the Windows console.  OTOH, having the console displayed on the screen seems to me to be a minor annoyance compared to having Octave crash.

John W. Eaton <jwe>
Project Administrator
Tue 03 May 2016 05:04:46 AM UTC, comment #106: 

There is still something weird with Windows that may, or may not be, Octave's fault.  I find that if I use a Windows cmd.exe window and cd to the bin directory of the Octave installation before starting octave.exe, then everything works.  If I go through the VBS file then I get the segfault.

If I change the desktop shortcut to just point to the Octave binary then it also works.  Maybe we could re-visit that decision.  We started using a vbs file because on some systems an extra cmd window would appear.  There was also an issue with running Octave the first time because it would come out minimized sometimed

Or we could give up, as jwe suggested, and bring the Magick functions into the core rather than having them be a dynamically linked library.

Rik <rik5>
Project Administrator
Sun 24 Apr 2016 01:01:33 PM UTC, comment #105: 

One more details, to this bug:

The observed crash on "test imread, clear all, test imread" after starting bin/octave-gui.exe does

  • only happen if Octave is installed on the Windows system via the nsis-INSTALLER file.
  • If you install the very same version of Octave via a ZIP-DIST folder, then it is NOT possible to provoke this crash.

I have tested this with the official 4.0.2 windows release installer and zip-dist, as well as with a self compiled installer and zip-dist.

This might also be the explanation why we thought that some recent patches had solved this issue. At least my own tests were only ever done with a zip-dist (because using the installer, always means uninstallling the other installation first).

Hartmut <hardy>
Sat 23 Apr 2016 09:16:06 AM UTC, comment #104: 

I have now also tested to use "octave.exe" in the vbs file, instead of "octave-gui.exe". And it does NOT avoid this bug. (It was just a quick idea, that doesn't work...)

Hartmut <hardy>
Fri 22 Apr 2016 05:00:00 PM UTC, comment #103: 

@jwe: Yes, I thought so.  I was merely confirming.  Tongue in cheek, but to publish an academic paper you need two points to make a line, and a third to confirm.  We now have 3 data points all indicating a failure so this is not a fluke.

Rik <rik5>
Project Administrator
Fri 22 Apr 2016 04:48:03 PM UTC, comment #102: 

Rik, I did my tests with 4.0.2.

John W. Eaton <jwe>
Project Administrator
Fri 22 Apr 2016 04:29:32 PM UTC, comment #101: 

For what it's worth, Harmut's and jwe's examples also segfault for me with version 4.0.2.

Rik <rik5>
Project Administrator
Fri 22 Apr 2016 03:51:24 PM UTC, comment #100: 

If this is a problem with loading/unloading the GraphicsMagick shared library, then I guess we could sidestep the issue by just making the functions that are defined in _magick_read_.cc core functions that are always linked with Octave instead of putting them in a dynamically linked .oct file.  Then the GraphicsMagick shared library would not be unloaded by "clear all".

John W. Eaton <jwe>
Project Administrator
Fri 22 Apr 2016 03:49:36 PM UTC, comment #99: 

I'm able to reproduce the crash with just

imwrite (randi (255, 100, 100), "foo.tif");
clear all
imwrite (randi (255, 100, 100), "foo.tif");

Octave does not crash if I change the filename (and thus the image type) to foo.png or foo.jpg.

I suppose it is still possible that the bug is in Octave, but it is looking more like a problem with GraphicsMagick now.

John W. Eaton <jwe>
Project Administrator
Fri 22 Apr 2016 02:39:16 PM UTC, comment #98: 

Well, that's odd.

I am able to duplicate this problem.  Unfortunately, when I just change octave-gui.exe to octave.exe in the .vbs file, I still see the crash.  Does that change avoid the problem for you?

I modified the script to run octave-gui.exe with gdb and it appears to be crashing due to an infinite recursion in UnregisterEPTImage in the GraphicsMagick library.

John W. Eaton <jwe>
Project Administrator
Fri 22 Apr 2016 01:27:19 PM UTC, comment #97: 

Bad news here. Please reopen this bug report.

I have just tested the official Windows installer of the Octave 4.0.2 release under Windows 7. (It should have all the relevant patches in.)

My observations are:

  • When I run "test imread, exit", then I never get any segfault. So far, so good.
  • When I run "test imread, clear all, test imread", then it  depends on how I start the Octave GUI. The following ways to start Octave DO CRASH on the above commands!
    • use the Desktop shortcut "Octave-4.0.2 (GUI)"
    • use the created shortcut in the Windows Start Menu
    • use /bin/octave-gui.exe
  • When I start Octave in the following different ways,then the commands "test imread, clear all, test imread" DO NOT CRASH.
    • use bin/octave-4.0.2.exe
    • use bin/octave.exe
    • use bin/octave-cli.exe

So there seems still to be something going on, which is special to Windows.

If this cannot be easily fixed, than my suggestion would be, that we keep "normal users" away from this crash, by replacing the currently used command "octave-gui.exe" by the well behaved command "octave.exe" in the startup file "octave.vbs". This would take care of the Desktop link (and also the start menu entry?)

Hartmut <hardy>
Fri 08 Apr 2016 07:50:17 PM UTC, comment #96: 

This has been fixed--finally--in this cset f3f8e1d3e399.  Closing report.

Rik <rik5>
Project Administrator
Sun 13 Mar 2016 06:36:47 PM UTC, comment #95: 

I think I have been able to finally isolate the same segfault on Linux using the AddressSanitizer.  See bug #47372.

Rik <rik5>
Project Administrator
Sun 06 Mar 2016 08:07:45 PM UTC, comment #94: 

This behavior on Windows is still present in the Octave-4.0.1-rc3 release candidate :(

Hartmut <hardy>
Thu 03 Dec 2015 10:41:32 PM UTC, comment #93: 

It's probably the same bug:

test imread
clear all
test imread

and

test imread
clear -f
test imread

crash Octave, but

test imread
clear -f imread
test imread

works.

Avinoam Kalma <avinoam>
Project Member
Thu 03 Dec 2015 05:18:40 PM UTC, comment #92: 

Re-testing with a recent tip (20787:62564952e161) crossbuilt with MXE and the problem is still there.

Using Mike's whatever.m script, the following segfaults

whatever
clear all

OR

whatever
exit

But the following works

whatever
clear -f whatever
exit

The following does not work

whatever
clear -f
clear all

This suggests that something in the cleanup routines is not correct.  When whatever.m is directly cleared, there is no segfault.  But when 'clear -f' is used there are apparently some things which are not cleaned up.

Rik <rik5>
Project Administrator
Tue 17 Nov 2015 02:11:37 PM UTC, comment #91: 

Let me point out another interesting thing: unlike octave.exe, octave-cli.exe does not crash on exit. As I understand, the CLI version is not compiled with Qt at all, perhaps this has something to do with it...

Here is a simple test to trigger the segfault:

# octave.exe
C:\> octave --no-gui --no-window-system --eval "imread('somefile.png'); disp('bye');"
warning: your version of GraphicsMagick limits images to 8 bits per pixel
warning: called from
    imformats>default_formats at line 256 column 11
    imformats at line 79 column 3
    imageIO at line 106 column 11
    imread at line 106 column 30
bye
panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

# octave-cli.exe
C:\> octave-cli --no-gui --no-window-system --eval "imread('somefile.png'); disp('bye');"
warning: your version of GraphicsMagick limits images to 8 bits per pixel
warning: called from
    imformats>default_formats at line 256 column 11
    imformats at line 79 column 3
    imageIO at line 106 column 11
    imread at line 106 column 30
bye

The above was tested in Octave 4.0.0 (the official Windows build).

Amro <amro_octave>
Mon 16 Mar 2015 04:42:42 PM UTC, comment #90: 

There is setting of rep to a static value that I thought it might be related to (deleting a memory block, that we never dynamically allocated) however looking at the code couldn't see how it would happen.

John Donoghue <lostbard>
Project Member
Mon 16 Mar 2015 03:41:43 PM UTC, comment #89: 

I used gdb in Windows to check various values at the time of the segfault.  First, I get the same backtrace as John D. in comment #88.  The code in question at Array.h:222 is

virtual ~Array (void)
{
  if (--rep->count == 0)
    delete rep;
}

The rep pointer is not null at this point, but there is something wrong because gdb will not let me read that memory location.  This may be related to the read-only property for the ICO and CUR formats.  This may also be the cause of the segfault.  The rep pointer is somehow set up in a region of memory that is read only.

From the Wikipedia page on virtual functions

Virtual destructors

Object-oriented languages typically manage memory allocation and de-allocation automatically when objects are created and destroyed. However, some object-oriented languages allow a custom destructor method to be implemented, if desired. If the language in question uses automatic memory management, the custom destructor (generally called a finalizer in this context) that is called is certain to be the appropriate one for the object in question. For example, if an object of type Wolf that inherits Animal is created, and both have custom destructors, the one called will be the one declared in Wolf.

In manual memory management contexts, the situation can be more complex, particularly as relates to static dispatch. If an object of type Wolf is created but pointed to by an Animal pointer, and it is this Animal pointer type that is deleted, the destructor called may actually be the one defined for Animal and not the one for Wolf, unless the destructor is virtual. This is particularly the case with C++, where the behavior is a common source of programming errors.

This looks scary, but it seems we are following the correct pattern and made the base object destructor a virtual function so that it can be overriden.

Rik <rik5>
Project Administrator
Sat 07 Mar 2015 02:34:39 AM UTC, comment #88: 

Running octave-4.0.0-rc1 with changeset head 19912:b8ce2f42815c

In windows 7, with debug symbols, after running test imread and then exit:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 14652.0x45b8]
Array<double>::~Array (this=0x2c732d58, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/Array.h:222
222     /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/Array.h: No such file or directory.

STack:

(gdb) where
#0  Array<double>::~Array (this=0x2c732d58, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/Array.h:222
#1  0x01092a93 in ~MArray (this=0x2c732d58, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/MArray.h:63
#2  ~NDArray (this=0x2c732d58, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/dNDArray.h:35
#3  ~octave_base_matrix (this=0x2c732d50, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-base-mat.h:68
#4  ~octave_matrix (this=0x2c732d50, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-re-mat.h:97
#5  octave_matrix::~octave_matrix (this=0x2c732d50, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-re-mat.h:97
#6  0x0112950a in ~ArrayRep (this=0x2c7e5168, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/Array.h:89
#7  Array<octave_value>::~Array (this=0x2c7ed44c, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/liboctave/array/Array.h:223
#8  0x0107a886 in _Destroy<Cell> (__pointer=0x2c7ed44c)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:93
#9  __destroy<Cell*> (__last=<optimized out>, __first=0x2c7ed44c)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:103
#10 _Destroy<Cell*> (__last=<optimized out>, __first=<optimized out>)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:126
#11 _Destroy<Cell*, Cell> (__last=0x2c7ed49c, __first=<optimized out>)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:151
#12 ~vector (this=0x2c86beec, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_vector.h:424
#13 octave_map::~octave_map (this=0x2c86bee8, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/oct-map.h:263
#14 0x0109bd75 in ~octave_struct (this=0x2c86bee0, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-struct.h:59
#15 octave_struct::~octave_struct (this=0x2c86bee0, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-struct.h:59
#16 0x0120ae7e in ~octave_value (this=0x2c6dc184, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov.h:314
#17 ~pair (this=0x2c6dc180, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_pair.h:96
#18 destroy (this=<optimized out>, __p=0x2c6dc180)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/ext/
new_allocator.h:133
#19 _M_destroy_node (this=0x2c6a7058, __p=0x2c6dc170)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_tree.h:409
#20 std::_Rb_tree<std::string, std::pair<std::string const, octave_value>, std::
_Select1st<std::pair<std::string const, octave_value> >, std::less<std::string>,
std::allocator<std::pair<std::string const, octave_value> > >::_M_erase (
    this=0x2c6a7058, __x=0x2c6dc170)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_tree.h:1247
#21 0x00b1a82e in ~_Rb_tree (this=0x2c6a7058, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_tree.h:715
#22 ~map (this=0x2c6a7058, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_map.h:96
#23 ~symbol_table (this=0x2c6a7020, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:2404
#24 erase_scope (scope=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:1228
#25 octave_user_function::~octave_user_function (this=this@entry=0x2c6b9b08,
    __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:233
#26 0x00b1aafb in octave_user_function::~octave_user_function (
    this=0x2c6b9b08, __in_chrg=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:234
#27 0x00f57808 in octave_value::operator= (this=this@entry=0x2c6a72b8, a=...)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave-value/ov.h:353
#28 0x0108a224 in clear_user_function (force=<optimized out>, this=0x2c6a7228)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:885
#29 clear (force=true, this=0x2c6a7228)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:910
#30 clear (force=true, this=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:1112
#31 clear_functions (force=<optimized out>)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:1689
#32 symbol_table::clear_all (force=force@entry=true)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.h:1661
#33 0x00f5b684 in symbol_table::cleanup ()
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/symtab.cc:1584
#34 0x00f9e9f8 in do_octave_atexit ()
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/toplev.cc:725
#35 0x00fa0342 in clean_up_and_exit (status=status@entry=0,
    safe_to_return=safe_to_return@entry=true)
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/corefcn/toplev.cc:762
#36 0x006e4e1a in octave_execute_interpreter ()
    at /home/jade/mxe-octave/tmp-default-octave/octave-4.0.0-rc1/libinterp/octave.cc:921
#37 0x2033737a in ZN14QMetaCallEvent13placeMetaCallEP7QObject ()
   from c:\Octave\octave-4.0.0-rc1\bin\QtCore4.dll
#38 0x28d90a60 in ?? ()
#39 0x679117fa in ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent ()
   from c:\Octave\octave-4.0.0-rc1\bin\QtGui4.dll
#40 0x00000044 in ?? ()
#41 0x208e0000 in ?? ()

John Donoghue <lostbard>
Project Member
Sat 28 Feb 2015 05:48:12 PM UTC, comment #87: 

I tested your 3 conditions for failure in comment #85 and they are accurate.  Changing any one is enough to make things work.

I'm grasping at straws here, but is there a destructor somewhere that isn't checking

if (ptr != NULL)
  free (ptr);

Also, could there be an order of destructor operation issue?

The following does not segfault.

whatever ()
clear -f whatever
exit

In this case the persistent variable is presumably cleanly destroyed and re-initialized and that is why it doesn't cause a segfault.  Maybe when you call exit() something comes along and destroys the persistent variable, but a second destructor comes along afterwards and attempts to do the same clean up. 

Rik <rik5>
Project Administrator
Sat 28 Feb 2015 07:02:16 AM UTC, comment #86: 

The unique thing about the formats "cur" and "ico" is that they are read-only via GraphicsMagick, all other formats are read/write.

I commented out the portion of _magick_formats_ that sets the "read" and "write" members to an empty value if the coder is registered as read-only. Octave no longer segfaults on exit.

I put that back, and then tried using octave_map::assign instead of octave_map::fast_elem_insert to see if that made a difference. Segfault on exit returns.

Mike Miller <mtmiller>
Project Administrator
Thu 26 Feb 2015 04:50:35 AM UTC, comment #85: 

Ok, here is a minimum working example that exhibits the segmentation fault when Octave exits.

function formats = whatever ()
  persistent formats = struct ( "coder", {},
                                "ext", {},
                                "isa", {},
                                "info", {},
                                "read", {},
                                "write", {},
                                "alpha", {},
                                "description", {},
                                "multipage", {});
  formats(1).coder = "CUR";
  formats = __magick_formats__ (formats);
endfunction

I was originally testing with "PNG" as the only format, but it did not segfault. Using "CUR" or "ICO" as the only format does segfault. So going back to the original imformats.m, commenting out both "CUR" and "ICO" no longer segfaults.

Is there something about these two formats in GraphicsMagick on Windows that would cause this segmentation fault or is it just random coincidence that it happens for me only with these two? Can someone else verify that commenting out these two formats in imformats.m fixes the segfault on exit?

So the combination of things that are required to cause the segfault for me are

  • persistent struct array in a function
  • copying the return value from the oct-file function _magick_formats_ into the persistent struct array
  • using the "CUR" or "ICO" image formats

If the struct array is not persistent, no segfault. If neither of those formats is passed into GM, no segfault. If the return value of _magick_formats_ is not assigned back into the struct array, no segfault.

Mike Miller <mtmiller>
Project Administrator
Wed 25 Feb 2015 12:42:09 AM UTC, comment #84: 

Alas, the problem still remains.  I checked the config.log for graphicsmagick and it is being built with -fopenmp.  I also have OMP_NUM_THREADS set to 1.

I ran octave-cli.exe under gdb and got a backtrace.  It's not tremendously helpful because the debugging symbols were stripped.  Still, it appears that we vector through the Fsylvester at #8.  That's really odd.

Program received signal SIGSEGV, Segmentation fault.
0x68cefb00 in liboctinterp-2!_ZN5ArrayIdED2Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 3600.0xe18 0x68cefb00 in liboctinterp-2!_ZN5ArrayIdED2Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
(gdb) bt
#0  0x68cefb00 in liboctinterp-2!_ZN5ArrayIdED2Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#1  0x68c48f93 in liboctinterp-2!_ZN13octave_matrixD0Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#2  0x68cdf6da in liboctinterp-2!_ZN5ArrayI12octave_valueED2Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#3  0x68c313b6 in liboctinterp-2!_ZN10octave_mapD1Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#4  0x68c52275 in liboctinterp-2!_ZN13octave_structD0Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#5  0x68dc02fe in liboctinterp-2!_ZNSt8_Rb_treeISsSt4pairIKSs12octave_valueESt10_Select1stIS3_ESt4le
ssISsESaIS3_EE8_M_eraseEPSt13_Rb_tree_nodeIS3_E ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#6  0x686ef83e in liboctinterp-2!_ZN20octave_user_functionD2Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#7  0x686efb0b in liboctinterp-2!_ZN20octave_user_functionD0Ev ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#8  0x68b1d7e8 in liboctinterp-2!_Z10FsylvesterRK17octave_value_listi ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#9  0x68c40734 in liboctinterp-2!_ZN12symbol_table9clear_allEb ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#10 0x68b214d4 in liboctinterp-2!_ZN12symbol_table7cleanupEv ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#11 0x68b64a48 in liboctinterp-2!_Z9main_loopv ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#12 0x68b66412 in liboctinterp-2!_Z17clean_up_and_exitib ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#13 0x682c47aa in octave_execute_interpreter ()
   from c:\Octave\Octave-3.9.1+\bin\liboctinterp-2.dll
#14 0x00402905 in ?? ()
#15 0x004013e2 in ?? ()
#16 0x7c817077 in RegisterWaitForInputIdle () from C:\WINDOWS\system32\kernel32.dll
#17 0x00000000 in ?? ()

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 10:40:49 PM UTC, comment #83: 

I'm still rebuilding with the patch from comment #81.  In a few hours I'll be able to give another test report.

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 10:14:03 PM UTC, comment #82: 

>> octave_config_info.XTRA_CXXFLAGS

ans = -pthread -fopenmp -mieee-fp

John Donoghue <lostbard>
Project Member
Tue 24 Feb 2015 06:54:13 PM UTC, comment #81: 

Updated patch that adds libgomp as a depenancy of graphicsmajick and copies the libgomp.dll.a to HOST_LIBDIR/ so that graphicsmagick compiles.

(file #33173)

John Donoghue <lostbard>
Project Member
Tue 24 Feb 2015 05:52:31 PM UTC, comment #80: 

I hope I didn't give the impression that building with OpenMP will definitely solve this problem. It might yet be a red herring. All I know is I saw a similar problem on Linux and that was definitely caused by GraphicsMagick being built with OpenMP and Octave not being built with it.

But all I've been able to determine about this bug is that it occurs when Octave is trying to clear a persistent variable from the symbol table during its exit procedures. And that persistent variable is a struct that does have something to do with entry points into the GraphicsMagick library.

Mike Miller <mtmiller>
Project Administrator
Tue 24 Feb 2015 05:43:04 PM UTC, comment #79: 

Looking at logs for previous builds, openblas, fftw, gettext also look for it

John Donoghue <lostbard>
Project Member
Tue 24 Feb 2015 04:40:21 PM UTC, comment #78: 

Trying to just re-build graphicsmagick, openmp is detected, but during the build I get this warning

*** Warning: This system can not link to static lib archive magick/libGraphicsMagick.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This system can not link to static lib archive magick/libGraphicsMagick.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: linker path does not have real file for library -lgomp.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgomp and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/rik/wip/Projects_Mine/mxe-octave/usr/i686-w64-mingw32/lib/libgdi32.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Eventually the build fails farther on because symbols are missing.  I did a 'make clean' and am going to try and re-build all of MXE-octave with support for OpenMP in place and see if it makes a difference.  This will take several hours.

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 04:21:42 PM UTC, comment #77: 

Some progress, but the bug still remains.

Checking config.log, I see that OpenMP is detected and that there are lots of instances of -fopenmp in the compilation step.

Installing in Windows and running Octave I can verify that

octave_config_info.features.OPENMP
ans =  1

But,

octave_config_info.CXXFLAGS
ans = -g -O2

I think this is because jwe modified the build process to put -pthreads and -fopenmp somewhere else.  Checking XTRA_CXXFLAGS,

XTRA_CXXFLAGS = -pthread -fopenmp -mieee-fp

So this seems okay.

But the acid test still fails,

octave:1> x = imformats ()
warning: your version of GraphicsMagick limits images to 8 bits per pixel
warning: called from
    imformats>default_formats at line 256 column 11
    imformats at line 79 column 3
x =

  1x17 struct array containing the fields:

    coder
    ext
    isa
    info
    read
    write
    alpha
    description
    multipage

octave:2> exit

panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Looking at the compile log, the dldfcn _magick_read_.cc is definitely built with -fopenmp.  Maybe we need to also build the graphics magick library with -fopenmp?

I looked in the log file for the MXE build of graphicsmagick and I see

checking for i686-w64-mingw32-gcc -std=gnu99 option to support OpenMP... unsupported

I'm going to try to rebuild graphicsmagick with John D's patch in place and see if that helps.

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 06:13:00 AM UTC, comment #76: 

The MXE build was broken for most of today, but is now restored, and I'm testing your patch.

I applied the patch, but MXE didn't seem to realize that it needed to rebuild libgomp.  I specifically rebuilt that component and am now re-building Octave.  I've checked the log file and OpenMP was detected and the correct compiler switches are being thrown so that's a start.  I won't have answers until tomorrow.

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 01:27:24 AM UTC, comment #75: 

I tried compiling it first however it doesnt detect it still in the configure.

I think the issue is that we are compiling libgomp and putting it where it will be needed for the native gcc (when in windows), however need it for the cross gcc whilst building octave.

I made a patch that copies the files to both the windows native and build gcc positions (attached) and it now gets detected at that point by configure.

I havent done a full compile yet, or install in windows to see whether it breaks anything else.

(file #33170)

John Donoghue <lostbard>
Project Member
Mon 23 Feb 2015 10:18:53 PM UTC, comment #74: 

Hmm.  Which solution do you think is better?  Octave itself makes no use of libgomp so it really isn't a dependency.  On the other hand, maybe in the future we do write conditional code that uses it.  Does making libgomp a dependency, and rebuilding, solve the issue?

Rik <rik5>
Project Administrator
Mon 23 Feb 2015 07:36:40 PM UTC, comment #73: 

omp.h is installed when libgomp is compiled which isn't a dependency currently for default-octave.mk

John Donoghue <lostbard>
Project Member
Mon 23 Feb 2015 01:21:24 AM UTC, comment #72: 

Maybe the sysroot settings used for compiling cross gcc are messing things up.

Currently they put them into usr/i686-w64-mingw32/lib/xxxxxx which looks different from the usr/lib/xxxx gcc is then trying to use.

When playing around with multilib gcc, I believe I had similar issues occuring when trying to compile gcc itself, and used usr as the sysroot rather usr/i686....

Perhaps the same is needed here?

John Donoghue <lostbard>
Project Member
Mon 23 Feb 2015 01:07:58 AM UTC, comment #71: 

.../i686-w64-mingw32/include is for the application/util includes etc, .../i686-w64-mingw32/lib/... is for the gcc includes, and usually gets looked at without requiring a -I option explicitly set.

[jade@speedster mxe-octave]$ usr/bin/i686-w64-mingw32-gcc -Wp,-v  t.c
ignoring nonexistent directory "/home/jade/mxe-octave/usr/i686-w64-mingw32/usr/local/include"
ignoring nonexistent directory "/home/jade/mxe-octave/usr/i686-w64-mingw32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
/home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include
/home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include-fixed
/home/jade/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/include
End of search list.

John Donoghue <lostbard>
Project Member
Mon 23 Feb 2015 12:16:47 AM UTC, comment #70: 

Actually, looking at the two paths I can see that the MXE-octave environment is using -I.../i686-w64-mingw32/include while the omp.h file is located in .../i686-w64-mingw32/lib/...

Don't know how to correct that though.  Does one patch ax_openmp.m4 for MXE?  Does one change the gcc recipe to copy over omp.h into the usual include directory?

Rik <rik5>
Project Administrator
Mon 23 Feb 2015 12:12:30 AM UTC, comment #69: 

@Mike: The problem seems to be the test compilation program which does #include <omp.h>.

configure:12529: checking for OpenMP flag of C compiler
configure:12571: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -pthread -fopenmp -I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-w64-mingw32/include -Wl,-rpath-link,/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-w64-mingw32/lib -L/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-w64-mingw32/lib conftest.c   >&5
conftest.c:41:17: fatal error: omp.h: No such file or directory
#include <omp.h>
                 ^
compilation terminated.

Does this mean that the host machine needs omp.h installed?  I did find omp.h on my host system.

The cross compiler environment in MXE alread seems to have omp.h installed.

find . -name 'omp.h'
./usr/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/4.9.2/include/omp.h
./usr/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/4.9.2/include/omp.h

Maybe the -I flags are not getting set correctly for cross-compilation of configure test files.

Rik <rik5>
Project Administrator
Sun 22 Feb 2015 11:48:14 PM UTC, comment #68: 

I'll try and locate the config.log and find out.

As for the openmp reporting, it looks like you might want to test whether the macro found anything before deciding to use OpenMP.  I added the following to configure.ac:

if test -n "$OPENMP_CFLAGS" && test -t "OPENMP_CXXFLAGS"; then
  CFLAGS="$CFLAGS $OPENMP_CFLAGS"
  CXXFLAGS="$CXXFLAGS $OPENMP_CXXFLAGS"
else
  USE_OPENMP=no
fi

Rik <rik5>
Project Administrator
Sun 22 Feb 2015 11:24:16 PM UTC, comment #67: 

Ok, good catch, I'll open another bug and try to get a fix for that in today. The "yes" in the summary is reporting whether the user chose to enable OpenMP, but not whether it was actually detected and found to be working.

Does the config.log say anything about why it is not detected in the cross-compiled mxe build?

Mike Miller <mtmiller>
Project Administrator
Sun 22 Feb 2015 11:16:33 PM UTC, comment #66: 

It seems that the cross-compiler in MXE has trouble finding the correct switches to throw.

checking for OpenMP flag of C compiler... unknown
checking for OpenMP flag of C++ compiler... unknown

Yet at the end of the configuration for MXE-octave.

OpenMP SMP multithreading:          yes

When I run the generated Octave under Windows, however,

-verbatim-
octave_config_info.features.OPENMP
ans = 0
-verbatim-

Now that we've switched to silent rules I can't tell whether '-fopenmp' is in any of the compilations, but

octave_config_info.CXXFLAGS
ans = -g -O2 -pthread

so I'm guessing not.

Rik <rik5>
Project Administrator
Sun 22 Feb 2015 10:33:43 PM UTC, comment #65: 

@Avinoam: can you confirm that OpenMP was used in the build:

>> octave_config_info.features.OPENMP
ans =  1
>> octave_config_info.CXXFLAGS
ans = -g -O2 -pthread -fopenmp

If yes, then this confirms what was hinted at earlier, that this may not be related to OpenMP (setting OMP_NUM_THREADS=1 had no effect on the failure).

Mike Miller <mtmiller>
Project Administrator
Sun 22 Feb 2015 10:09:58 PM UTC, comment #64: 

Using changeset 19821:ced2313b8d56, on windows,  the problem still exists:

octave:1> imformats ()
warning: your version of GraphicsMagick limits images to 8 bits per pixel
warning: called from
    imformats>default_formats at line 256 column 11
    imformats at line 79 column 3
error: imformats: pretty print not yet implemented.
error: called from
    imformats at line 82 column 5
octave:1> exit

panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Avinoam Kalma <avinoam>
Project Member
Sun 22 Feb 2015 03:58:57 PM UTC, comment #63: 

Bug #42176 has been cleared and Octave now builds with openmp enabled.  Could someone test whether this is still a problem?

Rik <rik5>
Project Administrator
Fri 06 Feb 2015 05:39:34 AM UTC, comment #62: 

And looking at the state of the stack a little more, Octave is trying to clear the function "imformats" and the variable "formats" within the function's symbol table when the crash occurs.

Mike Miller <mtmiller>
Project Administrator
Fri 06 Feb 2015 04:20:26 AM UTC, comment #61: 

All I can tell at the moment is that the crash on exit occurs when symbol_table::cleanup is being called while Octave is in the process of exiting.

#0  Array<double>::~Array (this=0x1a0dda10, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/liboctave/array/Array.h:222
#1  0x00e0f343 in ~MArray (this=0x1a0dda10, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/liboctave/array/MArray.h:63
#2  ~NDArray (this=0x1a0dda10, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/liboctave/array/dNDArray.h:35
#3  ~octave_base_matrix (this=0x1a0dda08, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-base-mat.h:68
#4  ~octave_matrix (this=0x1a0dda08, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-re-mat.h:97
#5  octave_matrix::~octave_matrix (this=0x1a0dda08, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-re-mat.h:97
#6  0x00ea5cea in ~ArrayRep (this=0x1a0be508, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/liboctave/array/Array.h:89
#7  Array<octave_value>::~Array (this=0x1a0f706c, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/liboctave/array/Array.h:223
#8  0x00df7546 in _Destroy<Cell> (__pointer=0x1a0f706c)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:93
#9  __destroy<Cell*> (__last=<optimized out>, __first=0x1a0f706c)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:103
#10 _Destroy<Cell*> (__last=<optimized out>, __first=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:126
#11 _Destroy<Cell*, Cell> (__last=0x1a0f70bc, __first=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_construct.h:151
#12 ~vector (this=0x1a0ef67c, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_vector.h:424
#13 octave_map::~octave_map (this=0x1a0ef678, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/oct-map.h:263
#14 0x00e18625 in ~octave_struct (this=0x1a0ef670, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-struct.h:59
#15 octave_struct::~octave_struct (this=0x1a0ef670, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-struct.h:59
#16 0x00f8685e in ~octave_value (this=0x1a07d954, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov.h:317
#17 ~pair (this=0x1a07d950, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_pair.h:96
#18 destroy (this=<optimized out>, __p=0x1a07d950)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/ext/new_allocator.h:133
#19 _M_destroy_node (this=0x1a06b610, __p=0x1a07d940)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_tree.h:409
#20 std::_Rb_tree<std::string, std::pair<std::string const, octave_value>, std::_Select1st<std::pair<std::string const, octave_value> >, std::less<std::string>, std::allocator<std::pair<std::string const, octave_value> > >::_M_erase (
    this=0x1a06b610, __x=0x1a07d940)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_tree.h:1247
#21 0x008b9b0e in ~_Rb_tree (this=0x1a06b610, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_tree.h:715
#22 ~map (this=0x1a06b610, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/usr/lib/gcc/i686-w64-mingw32/4.9.2/include/c++/bits/stl_map.h:96
#23 ~symbol_table (this=0x1a06b5d8, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:2404
#24 erase_scope (scope=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:1228
#25 octave_user_function::~octave_user_function (this=this@entry=0x19ff8db0,
    __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-usr-fcn.cc:233
#26 0x008b9ddb in octave_user_function::~octave_user_function (
    this=0x19ff8db0, __in_chrg=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov-usr-fcn.cc:234
#27 0x00ce3dd8 in octave_value::operator= (this=this@entry=0x179395a8, a=...)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave-value/ov.h:356
#28 0x00e06c94 in clear_user_function (force=<optimized out>, this=0x17939518)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:885
#29 clear (force=true, this=0x17939518)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:910
#30 clear (force=true, this=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:1112
#31 clear_functions (force=<optimized out>)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:1689
#32 symbol_table::clear_all (force=force@entry=true)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.h:1661
#33 0x00ce7b74 in symbol_table::cleanup ()
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/symtab.cc:1575
#34 0x00d2ac38 in do_octave_atexit ()
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/toplev.cc:725
#35 0x00d2c602 in clean_up_and_exit (retval=retval@entry=0,
    safe_to_return=safe_to_return@entry=true)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/corefcn/toplev.cc:762
#36 0x00484e1a in octave_execute_interpreter ()
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/libinterp/octave.cc:905
#37 0x00402905 in main (argc=2, argv=0x177422c0)
    at /srv/workspace/mike/src/mxe-octave/tmp-default-octave/octave-3.9.0+/src/main-cli.cc:42

Mike Miller <mtmiller>
Project Administrator
Thu 05 Feb 2015 11:12:54 AM UTC, comment #60: 

There is a static variable in __magic_read__cc:maybe_initialize_magick.

http://hg.savannah.gnu.org/hgweb/octave/file/0cdda69dc2b4/libinterp/dldfcn/__magick_read__.cc#l696

Could this be the cause of the problem?

Carnë Draug <carandraug>
Project Member
Thu 05 Feb 2015 06:09:59 AM UTC, comment #59: 

I just noticed an earlier bug report, this error had been found and narrowed down to GraphicsMagick a while ago but not fixed there either. Marking the dormant bug #40443 as a duplicate of this one, since there has been more recent progress on this report.

Mike Miller <mtmiller>
Project Administrator
Thu 05 Feb 2015 02:18:39 AM UTC, comment #58: 

I have a Windows VM now, and I can also confirm that the segfault still happens when Octave exits, but not on "clear all" anymore. Updating summary.

Also confirming that the

  formats = __magick_formats__ (formats);

line that sets up the formats struct is needed to get the segfault.

Mike Miller <mtmiller>
Project Administrator
Wed 04 Feb 2015 05:17:33 PM UTC, comment #57: 

I got the same result.

But, If do not comment this line, and I type "clear all",
there is no segfault until the line

  formats = __magick_formats__ (formats);

If I add "clear all" after this line, there is a segfault.

_magic_format_ is define in _magick_read_.oct, and the source
code is in _magick_read_.cc. should we try to debug it?

Avinoam Kalma <avinoam>
Project Member
Wed 04 Feb 2015 03:14:57 PM UTC, comment #56: 

The line that causes the segfault to occur is

    formats(fidx).coder = coders{fidx, 1};

None of the other lines cause the segfault.

When the above line is commented out I do get a bunch of

warning: implicit conversion from matrix to sq_string

Ian Journeaux <ijourneaux>
Wed 04 Feb 2015 11:06:13 AM UTC, comment #55: 

It does not segfault on 3.9.0+ when doing that because of memlock, but it still crashes when exiting Octave right?

Can you go through the imformats file in 3.8.2, and comment/uncomment the lines, while doing `imformats (); clear all;` until you find what exactly is causing the sefgault? We thought that the cause were the function handles to the private functions _imwrite_ etc. If it is not, you will have find that for us (I can't replicate this bug, I do not have windows).

Carnë Draug <carandraug>
Project Member
Wed 04 Feb 2015 05:46:45 AM UTC, comment #54: 

In the developement branch (ver 3.9.0+)
'imformats (); clear all;' does not cause a segfault

Avinoam Kalma <avinoam>
Project Member
Tue 03 Feb 2015 10:28:02 PM UTC, comment #53: 

After commenting out these lines in octave 3.8.2
'imformats (); clear all;' still causes a segfault

Avinoam Kalma <avinoam>
Project Member
Tue 03 Feb 2015 05:59:41 PM UTC, comment #52: 

It is kinda hard to debug this when we can't replicate this.

Running octave 3.8.2, 'imformats (); clear all;' causes a segfault, correct?

Could you then please go into your imformats.m file and comment the following lines:

    ## default isa is to check if the format returned by imfinfo is the coder
    formats(fidx).isa   = @(x) isa_magick (coders{fidx,1}, x);

and

  ## the default info, read, and write functions
  [formats.info ] = deal (@__imfinfo__);
  [formats.read ] = deal (@__imread__);
  [formats.write] = deal (@__imwrite__);

Then run 'imformats (); clear all;' Does it still segfault? If not, can you uncomment and check which of the above lines are causing the segfault? May be more than one.

Carnë Draug <carandraug>
Project Member
Tue 03 Feb 2015 02:48:58 PM UTC, comment #51: 

Sorry, using octave-cli & octave-gui on Windows-XP

Avinoam Kalma <avinoam>
Project Member
Tue 03 Feb 2015 02:48:06 PM UTC, comment #50: 

>> test bug-41699.tst
PASSES 1 out of 1 test

Using octave-cli & octave-cli on Windows-XP.

Avinoam Kalma <avinoam>
Project Member
Tue 03 Feb 2015 02:31:26 PM UTC, comment #49: 

Could you please check if the proposed test causes a segfault on your system? You need to:

1. download an extract the tar.gz file
2. cd into bug-41699
3. run "test "bug-41699.tst"

Does it causes a segfault? This bug seems to be triggered when clearing a function handle to a private function from memory which this test case tries to trigger.

(file #32984)

Carnë Draug <carandraug>
Project Member
Tue 03 Feb 2015 01:28:03 PM UTC, comment #48: 

Using Ian Journeaux for checking the shutdown crash,
It seems that there is still a segmentation fault when octave exits:

On Windows-XP with octave-cli

octave:1> cd c:\octave\tmp
octave:2> a=imread ('car.png');
warning: your version of GraphicsMagick limits images to 8 bits per pixel
warning: called from
    imformats>default_formats at line 256 column 11
    imformats at line 79 column 3
    imageIO at line 106 column 11
    imread at line 108 column 30
octave:3> exit

panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Avinoam Kalma <avinoam>
Project Member
Tue 03 Feb 2015 08:01:44 AM UTC, comment #47: 

Good news!

I have checked the version with the new change on Windows
(win7 & win xp), which suffer from crash after
imread & clear all, and it is fixed now.

I am not sure about the shutdown crash. How can I check this?

Avinoam Kalma <avinoam>
Project Member
Mon 02 Feb 2015 10:32:19 PM UTC, comment #46: 

I just pushed a change (b95aab49b6be) to octave which while not aiming at fixing this issue may affect it.  This is because the bug is trigered when clearing the formats persistent variable from imformats, but this variable should not have been cleared in the first place. I just added a memlock to it.

The crash may still happen at shutdown, can someone with windows and previously affected with this bug please try?

Carnë Draug <carandraug>
Project Member
Mon 03 Nov 2014 08:35:26 PM UTC, comment #45: 

Hi,

Running octave in debug mode, and typing imread ("file") and
clear all, give the following lines:

Reducing stack by rule 272 (line 1620):
Stack now 0
octave:2> clear all
Starting parse
Entering state 0
Reading a token: Next token is token NAME () Shifting token NAME () Entering state 9 Reducing stack by rule 19 (line 430):
   $1 = token NAME ()
-> $$ = nterm identifier ()
Stack now 0
Entering state 41
Return for a new token:
Reading a token: Next token is token SQ_STRING () Shifting token SQ_STRING () Entering state 11 Reducing stack by rule 23 (line 448):
   $1 = token SQ_STRING ()
-> $$ = nterm string ()
Stack now 0 41
Entering state 121
Reducing stack by rule 17 (line 417):
   $1 = nterm string ()
-> $$ = nterm word_list ()
Stack now 0 41
Entering state 120
Return for a new token:
Reading a token: Next token is token '\n' () Reducing stack by rule 16 (line 406):
   $1 = nterm identifier ()
   $2 = nterm word_list ()
-> $$ = nterm word_list_cmd ()
Stack now 0
Entering state 40
Reducing stack by rule 15 (line 394):
   $1 = nterm word_list_cmd ()
-> $$ = nterm statement ()
Stack now 0
Entering state 39
Reducing stack by rule 6 (line 368):
   $1 = nterm statement ()
-> $$ = nterm simple_list1 ()
Stack now 0
Entering state 38
Next token is token '\n' ()
Reducing stack by rule 261 (line 1593):
-> $$ = nterm opt_sep_no_nl ()
Stack now 0 38
Entering state 119
Reducing stack by rule 5 (line 364):
   $1 = nterm simple_list1 ()
   $2 = nterm opt_sep_no_nl ()
-> $$ = nterm simple_list ()
Stack now 0
Entering state 37
Next token is token '\n' ()
Shifting token '\n' ()
Entering state 117
Reducing stack by rule 1 (line 347):
   $1 = nterm simple_list ()
   $2 = token '\n' ()
Stack now 0
panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Thanks,
Avinoam

Avinoam Kalma <avinoam>
Project Member
Tue 15 Jul 2014 02:24:30 PM UTC, comment #44: 

No. This should not be pushed.

There is a reason we are using a persistent variable there. The variable needs to be persistent in order to imformats() work properly. Even for people who do not change the default imageIO functions, keeping that persistent means that Octave does not have to recalculate what functions to use each time you call an imageIO function.

This just points closer to where the bug is. The issue seems to be with having a persistent variable with handles for private functions.

Carnë Draug <carandraug>
Project Member
Mon 14 Jul 2014 08:10:37 PM UTC, comment #43: 

should this change be pushed?

too bad it's not part of image package,
so it'll take longer for the fixed version
of the octave based to reach users.

just to restate, clear all triggers a segfault, clear doesn't.

Felipe G. Nievinski <fgnievinski>
Mon 14 Jul 2014 04:18:47 PM UTC, comment #42: 

Although removing persistent from the imformats. m script file eliminates the segfault, it is probably not the ultimate solution. As for why this error occurs, I would recommend discussing with Carne as he was the one to first bring up imformats.m as the cause.

Ian Journeaux <ijourneaux>
Fri 11 Jul 2014 03:04:54 PM UTC, comment #41: 

So does this indicate that the error is due to a dependence between the persistent struct array and the dynamically-loaded GrahpicsMagick library? Exiting Octave or executing "clear -f" unloads the GraphicsMagick dynamic library, could this be taking away something or destroying something that the persistent variable references?

Mike Miller <mtmiller>
Project Administrator
Fri 11 Jul 2014 01:21:27 PM UTC, comment #40: 

As recommended by Dan and Carne on the mailing list, removing persistent from the imformats.m file eliminated the Octave crashes I was experiencing.

Removed persistant  from these two lines in imformats.m
formats = default_formats ();
formats = struct ( "coder", {},
                                "ext", {},
                                "isa", {},
                                "info", {},
                                "read", {},
                                "write", {},
                                "alpha", {},
                                "description", {},
                                "multipage", {});

Ian Journeaux <ijourneaux>
Wed 04 Jun 2014 05:15:43 AM UTC, comment #39: 

I stepped up the backtrace. When doing that I found this in the source. The back trace goes though line 236 which is

  symbol_table::erase_scope (local_scope);

which has a "// FIXME: this is really playing with fire." comment.
Useful info or just a red herring?

octave_user_function::~octave_user_function (void)
{
  if (cmd_list)
    cmd_list->remove_all_breakpoints (file_name);

  delete param_list;
  delete ret_list;
  delete cmd_list;
  delete lead_comm;
  delete trail_comm;

#ifdef HAVE_LLVM
  delete jit_info;
#endif

  // FIXME: this is really playing with fire.
  symbol_table::erase_scope (local_scope);
}

Ian Journeaux <ijourneaux>
Tue 03 Jun 2014 02:02:09 PM UTC, comment #38: 

Is this possibly related to the problem with clear all with earlier versions of Octave (under windows)?

Is there a way to create a full MXE-Octave debugging environment under windows. Philip pointed me to the dlls with symbols this improves the amount of info available when debugging with gdb but all that got me was to the array.h include that is not found.

Ian Journeaux <ijourneaux>
Tue 03 Jun 2014 01:17:39 PM UTC, comment #37: 

I'm not sure that clearing individual functions is unloading the oct-file in this case, and I don't know why, either a bug or something I don't understand. But dlclose is not called when any __magick* functions are cleared, only when clear -f is used.

So all the evidence still points to this being due to unloading the GraphicsMagick DLL while Octave is still running or when Octave exits.

Mike Miller <mtmiller>
Project Administrator
Tue 03 Jun 2014 11:47:36 AM UTC, comment #36: 

All of these options only result is an Octave segfault when you exit octave. This compares to

clear -f

or

clear functions

which cause an immediate crash.

Ian Journeaux <ijourneaux>
Tue 03 Jun 2014 05:59:42 AM UTC, comment #35: 

Could you run (line by line)

test imread
clear __magick_formats__
clear __magick_finfo__
clear __magick_write__
clear __magick_ping__
clear __magick_read__

and see when it crashes?

Andreas Weber <andy1978>
Project Member
Mon 02 Jun 2014 11:11:33 PM UTC, comment #34: 

A couple of clarifications
test imread;
followed by

clear -f
or
clear functions

cause an immediate octave crash back to a dos prompt.

test imead;
followed by
clear _magick_read_

leaves Octave running but when you exit Octave you get the same segmentation fault.

Ian Journeaux <ijourneaux>
Mon 02 Jun 2014 09:24:35 PM UTC, comment #33: 

After test imread

clear -f
clear functions

cause the segmentation fault

clear _magick_read_

doesn't result in a segmentation fault.

Ian Journeaux <ijourneaux>
Mon 02 Jun 2014 09:12:08 PM UTC, comment #32: 

Even though we have proven (I think?) that this is not related to GraphicsMagick's use of OpenMP (see bug #42176), this still looks to me to be related to unloading the _magick_read_.oct file, which in turn unloads and runs destructors in the GraphicsMagick library because it is only linked to that one oct-file. And this seems to be doing something that crashes Octave on Windows.

Note that "clear all" clears functions from the symbol table. You should also be able to reproduce this crash with any of the following after "test imread":

clear -f
clear functions
clear __magick_read__

I can get the same crash on Linux but only because of OpenMP. By defining OMP_NUM_THREADS=1, or building Octave with --enable-openmp, the crash does not happen on Linux.

Earlier in this report we saw that defining OMP_NUM_THREADS=1 has no effect and still crashes Octave on Windows.

Mike Miller <mtmiller>
Project Administrator
Mon 02 Jun 2014 08:45:14 PM UTC, comment #31: 

Since this seems to replicate the bug reported in 42488. Here are a couple of pertinent details

test imread;
clear all;

causes octave to crash hard.

Any thoughts on how to troubleshoot would be greatly appreciated.

Ian Journeaux <ijourneaux>
Sat 24 May 2014 02:04:00 AM UTC, comment #30: 

Just rebuild Octave via MXE to see if there was any change in behavior.

test imread
exit(0)

still produces a segfault as you exit Octave.
Here is the error message.

octave:2> exit
warning: Invalid parameter passed to C runtime function.

error: writing file 'U:\.octave_hist': No such file or directory
error: ignoring octave_execution_exception while preparing to exit

Program received signal SIGSEGV, Segmentation fault.
0x68a807c0 in liboctinterp-2!_ZN5ArrayIdED2Ev ()
   from C:\Octave\Octave-3.8.1\bin\liboctinterp-2.dll

Ian Journeaux <ijourneaux>
Tue 22 Apr 2014 01:56:17 PM UTC, comment #29: 

getenv OMP_NUM_THREADS inside of Octave returns 1. Rats!!!
I was hoping that the errors were related.

Thanks for the discussion.  I am all ears if you have other thoughts.

Ian Journeaux <ijourneaux>
Tue 22 Apr 2014 01:46:49 PM UTC, comment #28: 

Since I'm not that familiar with Windows, can you verify that the value was propagated into Octave by running "getenv OMP_NUM_THREADS" at the Octave prompt? It should say "ans = 1". If not, then try "setenv OMP_NUM_THREADS 1" within Octave.

If that's not fixing your crash, then we are back to this being unrelated to the segfault I see on Linux.

Mike Miller <mtmiller>
Project Administrator
Tue 22 Apr 2014 01:40:24 PM UTC, comment #27: 

Here is what I tried on my Windows 7 machine

1. Open up a command window
2. Set OMP_NUM_THREADS=1
3. run Octave-cli.exe
4. test imread
5. exit(0)

panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

I also tried running Octave-cli with GDB (no debug info though)
and got

Program received signal SIGSEGV, Segmentation fault.
0x68821aa0 in liboctinterp-2!_ZN5ArrayIdED2Ev ()
   from C:\Octave\Octave-3.8.1\bin\liboctinterp-2.dll

I wonder if GraphicsMagick under windows actually uses the OMP_NUM_THREADS=1 environment variable

I can install the debug version of the different DLLs if that would be useful

Ian Journeaux <ijourneaux>
Mon 21 Apr 2014 10:59:54 PM UTC, comment #26: 

Ok, I now have an explanation for this bug, all I need is for you to confirm that your segfault on Windows is due to OpenMP / libgomp by setting OMP_NUM_THREADS=1 and confirming that the crash no longer happens.

The cause of the segfault looks to me to be because the image functions are implemented in an oct-file. This oct-file links to the GraphicsMagick library, which uses OpenMP. When Octave exits, it attempts to unload all oct-files that were loaded during its execution. Unloading the oct-file for _magick_read_ causes the libgomp library to be unloaded since Octave is not using it for anything else. If OpenMP threads were launched during the run, this causes a segfault in one of the OpenMP threads because the library implementing them has been unloaded from the process space.

I can reproduce this crash with a standard C main function calling dlopen to load a plugin, which then does some simple OpenMP loop. Calling dlclose on the plugin causes the same exact segfault.

One solution is to compile Octave with OpenMP enabled. This causes libgomp to be linked with the Octave libraries and executables, and therefore it won't be unloaded when the oct-file is unloaded. This seems like a good solution, especially if users may implement their own oct-files that use OpenMP, which may then cause a crash when the oct-files are unloaded.

Another solution is to compile GraphicsMagick without OpenMP (--disable-openmp to GraphicsMagick's configure). This might work for the MXE build, but we can't control this for Linux distros or other packaging systems. This also does not solve the point about users wanting to write oct-files using OpenMP.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Apr 2014 08:33:16 PM UTC, comment #25: 

I just thought of something very easy you can try that might shed some light on whether the segfault you are seeing on Windows is the same that I am seeing.

Try setting the OMP_NUM_THREADS environment variable to 1 before any image functions are called. If you're running from a msys shell or other unixy-type shell, you could export OMP_NUM_THREADS=1 from there before calling octave. If not, set it in the Octave shell before your scripts or any image-related functions are called:

setenv OMP_NUM_THREADS 1;

This prevents OpenMP from spawning additional threads in the background, and, at least for the condition I see, prevents the segfault from occurring at exit.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Apr 2014 07:20:45 PM UTC, comment #24: 

I'm also unsure under what conditions this is triggered. For example, on Linux running "test imread" does not cause the error on exit. All I can say it seems to be due to GraphicsMagick using OpenMP, at least on my Linux distribution, I'm not sure if that's the case using MXE. I also only see the segfault when running octave in gdb.

The thing that led me to look into OpenMP was that gdb showed new threads starting when I called imread to open your tif file. I knew that Octave would not be starting those threads, so it looked like it was internal to GraphicsMagick.

So my questions are, does GraphicsMagick built in MXE use OpenMP (built with gcc -fopenmp and/or linked with libgomp)? Are threads observed to start when calling certain im* functions in Octave? Is libgomp available in the MXE gcc environment? Does gcc -fopenmp work as expected when building things in MXE? Is --enable-openmp expected to work for Octave in MXE? Are the resulting octave libraries and executables linked with libgomp? If GraphicsMagick is and Octave isn't, then what else is needed to link Octave with libgomp, and if that is done, does it fix the error?

Mike Miller <mtmiller>
Project Administrator
Mon 21 Apr 2014 06:44:22 PM UTC, comment #23: 

Interestingly, I was running tests on some of my older more complex scripts that include several calls to imread and imwrite statements.

At least in the case of one of the scripts, the script completes and I can exit Octave without getting the segmentation violation error. I ran 20+ samples through the script without any problems.

Although I am learning more about octave and how to build it, I am still having trouble figuring out how to troubleshoot this type of error and provide useful information.

Ian Journeaux <ijourneaux>
Sun 20 Apr 2014 09:05:49 PM UTC, comment #22: 

Mike

I was able to add the command --enable-openmp to octave.mk right after

    --enable-atomic-refcount \
    --enable-openmp \

This compiled up without errors but, atleast under windows, I still have the segmentation violation exiting octave-cli after  a call to "test imread".

Ian Journeaux <ijourneaux>
Sun 20 Apr 2014 04:06:41 PM UTC, comment #21: 

Yes, if you're building mxe-octave yourself I think you can add --enable-openmp to the src/octave.mk file that builds Octave. I haven't built it with mxe in a while, but it looks like there are some variables in that file for configure flags. You might want to add it to one of the CONFIGURE_OPTIONS variables that you know are being used, e.g. $(PKG)_EXTRA_CONFIGURE_OPTIONS.

If that doesn't work, then there may be some other dependencies that are needed to get it to compile with OpenMP for Windows.

Mike Miller <mtmiller>
Project Administrator
Sun 20 Apr 2014 03:21:56 PM UTC, comment #20: 

Mike

I am working under Windows. Is there something I can try when building MXE-Octave to test this.

Ian

Ian Journeaux <ijourneaux>
Sat 19 Apr 2014 05:51:14 PM UTC, comment #19: 

Running 'test imread' does not cause a segfault on exit on Linux. But loading the original tif you provided does.

I think this is tied to OpenMP. The GraphicsMagick library is built with OpenMP and Octave is not (by default). If I use --enable-openmp when building Octave, there is no segfault.

Should we force use of OpenMP in Octave when using GraphicsMagick?

Mike Miller <mtmiller>
Project Administrator
Fri 11 Apr 2014 09:34:00 PM UTC, comment #18: 

Here is an even easier way to replicate

test imread
exit(0)

Ian Journeaux <ijourneaux>
Fri 11 Apr 2014 05:31:41 PM UTC, comment #17: 

Using fresh build of me octave under win7 mike's steps produce the same segmentation fault

Ian Journeaux <ijourneaux>
Fri 11 Apr 2014 04:58:22 PM UTC, comment #16: 

Following Mike Miller example I can reproduce the issue.

Carnë Draug <carandraug>
Project Member
Thu 10 Apr 2014 01:51:09 AM UTC, comment #15: 

This may or may not be related, but I get the following segfault on exit when running Octave 3.8.1 on linux with gdb. If I run Octave without gdb, I don't see any error, I'm not sure if that means it's being suppressed somehow because it's when the process is exiting, or if gdb is changing the process environment sufficiently to trigger the error.

Showing here with a fresh build of the stable branch:

$ ./run-octave -g --no-gui-libs
...
(gdb) run
...
octave:1> imread (tilde_expand ("~/Downloads/AI3c70.tif"));
warning: your version of GraphicsMagick limits images to 8 bits per pixel
octave:2> exit


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe2a02700 (LWP 31274)]
0x00007fffe4170a70 in ?? ()
(gdb) info threads
  Id   Target Id         Frame
  4    Thread 0x7fffe2201700 (LWP 31275) "lt-octave-cli" 0x00007fffe4170a72 in ?? ()
* 3    Thread 0x7fffe2a02700 (LWP 31274) "lt-octave-cli" 0x00007fffe4170a70 in ?? ()
  2    Thread 0x7fffe3203700 (LWP 31273) "lt-octave-cli" 0x00007fffe4170a72 in ?? ()
  1    Thread 0x7ffff7f8d780 (LWP 31242) "lt-octave-cli" _dl_close_worker (
    map=map@entry=0xc9f430) at dl-close.c:755
(gdb) thread apply all bt

Thread 4 (Thread 0x7fffe2201700 (LWP 31275)):
#0  0x00007fffe4170a72 in ?? ()
#1  0x00007fffe416f2fe in ?? ()
#2  0x00007fffe2201700 in ?? ()
#3  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7fffe2a02700 (LWP 31274)):
#0  0x00007fffe4170a70 in ?? ()
#1  0x00007fffe416f2fe in ?? ()
#2  0x00007fffe2a02700 in ?? ()
#3  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7fffe3203700 (LWP 31273)):
#0  0x00007fffe4170a72 in ?? ()
#1  0x00007fffe416f2fe in ?? ()
#2  0x00007fffe3203700 in ?? ()
#3  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7f8d780 (LWP 31242)):
#0  _dl_close_worker (map=map@entry=0xc9f430) at dl-close.c:755
#1  0x00007ffff7df11ec in _dl_close (_map=0xc9f430) at dl-close.c:781
#2  0x00007ffff7deb7b4 in _dl_catch_error (objname=0x9ed7e0, errstring=0x9ed7e8,
    mallocedp=0x9ed7d8, operate=0x7fffefe390e0 <dlclose_doit>, args=0xc9f430)
    at dl-error.c:177
#3  0x00007fffefe395dd in _dlerror_run (operate=operate@entry=0x7fffefe390e0 <dlclose_doit>,
    args=0xc9f430) at dlerror.c:163
#4  0x00007fffefe3910f in __dlclose (handle=<optimized out>) at dlclose.c:46
#5  0x00007ffff694241d in octave_dlopen_shlib::~octave_dlopen_shlib (this=0xcf8b20,
    __in_chrg=<optimized out>) at ../../liboctave/util/oct-shlib.cc:215
#6  0x00007ffff6942599 in octave_dlopen_shlib::~octave_dlopen_shlib (this=0xcf8b20,
    __in_chrg=<optimized out>) at ../../liboctave/util/oct-shlib.cc:216
#7  0x00007ffff75819a1 in operator= (sl=..., this=0x778798)
    at ../../liboctave/util/oct-shlib.h:135
#8  close (cl_hook=0x0, this=0x778798) at ../../liboctave/util/oct-shlib.h:157
#9  octave_shlib_list::do_remove (this=<optimized out>, shl=..., cl_hook=0x0)
    at ../../libinterp/corefcn/dynamic-ld.cc:116
#10 0x00007ffff7581f78 in octave_dynamic_loader::do_remove_oct (this=0x0, fcn_name=...,
    shl=...) at ../../libinterp/corefcn/dynamic-ld.cc:391
#11 0x00007ffff7581fcb in octave_dynamic_loader::remove_oct (fcn_name=..., shl=...)
    at ../../libinterp/corefcn/dynamic-ld.cc:439
---Type <return> to continue, or q <return> to quit---
#12 0x00007ffff73a97fa in octave_dld_function::~octave_dld_function (this=0x778750,
    __in_chrg=<optimized out>) at ../../libinterp/octave-value/ov-dld-fcn.cc:59
#13 0x00007ffff73a99f9 in octave_dld_function::~octave_dld_function (this=0x778750,
    __in_chrg=<optimized out>) at ../../libinterp/octave-value/ov-dld-fcn.cc:60
#14 0x00007ffff78303bb in octave_value::operator= (this=this@entry=0xd1a628, a=...)
    at ../../libinterp/octave-value/ov.h:357
#15 0x00007ffff783537f in clear_user_function (force=true, this=0xd1a510)
    at ../../libinterp/corefcn/symtab.h:874
#16 clear (force=true, this=0xd1a510) at ../../libinterp/corefcn/symtab.h:894
#17 clear (force=true, this=0xd1b218) at ../../libinterp/corefcn/symtab.h:1083
#18 clear_functions (force=true) at ../../libinterp/corefcn/symtab.h:1660
#19 clear_all (force=true) at ../../libinterp/corefcn/symtab.h:1632
#20 symbol_table::cleanup () at ../../libinterp/corefcn/symtab.cc:1474
#21 0x00007ffff7860755 in do_octave_atexit () at ../../libinterp/corefcn/toplev.cc:693
#22 0x00007ffff7861ddf in clean_up_and_exit (retval=0, safe_to_return=<optimized out>)
    at ../../libinterp/corefcn/toplev.cc:730
#23 0x00007ffff708195c in octave_execute_interpreter () at ../../libinterp/octave.cc:893
#24 0x00007ffff4bc4b45 in __libc_start_main (main=0x400920 <main(int, char**)>, argc=8,
    argv=0x7fffffffc1d8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffc1c8) at libc-start.c:287
#25 0x00000000004009af in _start ()

If it is the same root cause, this shows an example of imread by itself causing a segfault on exit.

Mike Miller <mtmiller>
Project Administrator
Fri 04 Apr 2014 05:16:07 PM UTC, comment #14: 

Yes are are correct. The seg fault only occur when you exit Octave.

Ian Journeaux <ijourneaux>
Fri 04 Apr 2014 04:35:16 PM UTC, comment #13: 

Just be clear, you only get a segmentation fault when you exit Octave, correct? So to replicate it, you need to run:

a = repmat (uint8 (0:255), 100, 1);
imwrite (a, "test.jpg");
b = imrotate (a, 5, "nearest", "crop");
exit ();

Carnë Draug <carandraug>
Project Member
Fri 04 Apr 2014 02:03:11 AM UTC, comment #12: 

I have got myself to the point where I can build MXE Octave and start to diagnose.

When I start up Octave with GDB, I am able to reproduce the problem.

C:\MinGW\bin>gdb C:\Octave\Octave-3.8.1\bin\octave-gui.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\Octave\Octave-3.8.1\bin\octave-gui.exe...done.
(gdb) run
Starting program: C:\Octave\Octave-3.8.1\bin\octave-gui.exe
[New Thread 1840.0x2700]
[New Thread 1840.0x2aac]
[New Thread 1840.0x5c0]
[New Thread 1840.0x1fc4]
[New Thread 1840.0x2a74]
[New Thread 1840.0x2298]
[New Thread 1840.0xe2c]
[New Thread 1840.0x2e70]
[New Thread 1840.0x1ea8]
[New Thread 1840.0x2a7c]
[New Thread 1840.0x2550]
[New Thread 1840.0x2fe8]
warning: Invalid parameter passed to C runtime function.
warning: Invalid parameter passed to C runtime function.
...
warning: Invalid parameter passed to C runtime function.
warning: SNACNP::NPGetCaps::WNNC_NET_TYPE
warning: SNACNP::NPGetCaps::WNNC_USER
warning: SNACNP::NPGetCaps::WNNC_CONNECTION
warning: SNACNP::NPGetCaps::WNNC_ENUMERATION
warning: SNACNP::NPGetCaps::WNNC_ADMIN
warning: SNACNP::NPGetCaps::WNNC_DIALOG
warning: SNACNP::NPGetCaps::WNNC_START
[New Thread 1840.0x22a0]
warning: Invalid parameter passed to C runtime function.
...
warning: Invalid parameter passed to C runtime function.
[New Thread 1840.0x2de0]
warning: Invalid parameter passed to C runtime function.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 11456.0x10d8]
Array<double>::~Array (this=0x1d964db8, __in_chrg=<optimized out>)
    at /mxe-octave/tmp-stable-octave/octave-3.8.1/liboctave/array/Array.h:243
243     /mxe-octave/tmp-stable-octave/octave-3.8.1/liboctave/array/Array.h: No such file or directory.

I am just not sure how to go about diagnosing this further. I would tend to think the the problem is a result of a conflict with something in the GraphicMagik package used by imwrite or the image package but that is just a hunch.

Ian Journeaux <ijourneaux>
Tue 11 Mar 2014 07:58:38 PM UTC, comment #11: 

This problem persists with the latest version of Octave 3.8.1.

Here is a simple way to reproduce the error

a = repmat (uint8 (0:255), 100, 1);
imwrite (a, "test.jpg");
b=imrotate(a,5,'nearest','crop');

Ian Journeaux <ijourneaux>
Fri 28 Feb 2014 12:54:38 AM UTC, comment #10: 

I am having trouble coming up with a subset that replicates the problem.
imread by itself - no problem
imrotate ot imremap by itself - no problem
imread + imremap - segmentation violation.

Any thoughts on why imread and imremap together would cause a problem

Ian Journeaux <ijourneaux>
Thu 27 Feb 2014 05:12:23 PM UTC, comment #9: 

It might be appropriate to close this as the bug doesn't seem to be related (at least directly) to imrotate and is more likely related to imread.

The odd part though is that imread by itself is not sufficient to cause the segmentation violation.

It is interesting in one of my scripts, I make multiple calls to imread and imrotate. When the script terminates normally, I don't get a segmentation violation error when exiting Octave. BUT if I add a return statement immediately after the first call to imread, the script terminates without error but when I exit Octave, I get the segmentation violation error.

Ian

Ian Journeaux <ijourneaux>
Wed 26 Feb 2014 09:51:07 PM UTC, comment #8: 

One more test

AI3c2=imread('AI3c70.tif');

Doesn't cause a segmentation violation so the imread by itself is not sufficent to cause the problem.

Ian Journeaux <ijourneaux>
Wed 26 Feb 2014 09:23:58 PM UTC, comment #7: 

After some more testing, it appears that the problem is not related to the version of the image package.

To eliminate memory as a possible issue, I reduced the size of the array

AI3c1=imread('AI3c70.tif');
AI3c = AI3c1(1:5,1:5)
AI3cr=imrotate(AI3c,5,'nearest','crop');

This still generates the error so I further simplified the test program to just the 5x5 array read in from the image

AI3c1 = [88,  113,  120,  126,  132;
  113,  142,  151,  161,  170;
  120,  151,  161,  170,  179;
  126,  161,  170,  179,  189;
  132,  170,  179,  189,  198;]
AI3cr=imrotate(AI3c1,5,'nearest','crop');

This works. Then tried

AI3c2=imread('AI3c70.tif');
% AI3c2 is unused.
AI3c1 = [88,  113,  120,  126,  132;
  113,  142,  151,  161,  170;
  120,  151,  161,  170,  179;
  126,  161,  170,  179,  189;
  132,  170,  179,  189,  198;]
AI3cr=imrotate(AI3c1,5,'nearest','crop');

This results in the segmentation violation on exiting Octave.
It would appear that the problem is associated with imread.

Ian Journeaux <ijourneaux>
Wed 26 Feb 2014 09:13:18 PM UTC, comment #6: 

The only change to imrotate should had been to allow more interpolation methods, but all that does is skip check the interpolation option and leave that up to interp2.

I have tried in both i686 and amd64 (Linux only) and still can't replicate this problem.

Carnë Draug <carandraug>
Project Member
Wed 26 Feb 2014 07:04:31 PM UTC, comment #5: 

Further testing: The segmentation violation does not occur with image 2.0.0

Ian Journeaux <ijourneaux>
Wed 26 Feb 2014 06:51:15 PM UTC, comment #4: 

I did some more work this morning to see if I could get more information on the problem.

AI3c=imread('AI3c70.tif');
AI3cr=imrotate(AI3c,5,'nearest','crop');
The dimensions of the image AI3c are 5401 x 519

This completes without error but when I exit Octave, I get a segmentation violation

Simplyfing even more, I create a synthetic array of the same dimensions

AI3c(1:6001,1:601) = 38;
AI3cr=imrotate(AI3c,5,'nearest','crop');

This completes without error and I do not get a segmentation violation when exiting Octave.

There are no changes to the image 2.2.0 source.

Ian Journeaux <ijourneaux>
Wed 26 Feb 2014 04:33:45 PM UTC, comment #3: 

Good memory.
I believe the only change I had made was to imresize so that the arrays produced by meshgrid were single instead of double arrays.

But just to be safe, I unloaded, uninstalled and reinstalled image-2.2.0 to erase and potential changes I might have made.

I get the same behavior.

testimrotate completes without error. but when I exit Octave I get a segmentation fault

The diary file only has

attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

While the text on the octave screen after I try to exit is

0x6886cbc0 (0x0022fafa 0x00000000 0x0022ffc4 0x77ce8cd5), _zn5ArrayIdED2Ev() + 0x10 byte(s)
panic Segmentation violation -- stopping myself...

Ian Journeaux <ijourneaux>
Wed 26 Feb 2014 11:25:22 AM UTC, comment #2: 

Works for me using Octave 3.8.0 and image package 2.2.0.

I remember you saying on the mailing list that you had out of memory problems which you solved by modifying the class of some variables in imremap and imresize. Are you still using a modified version of those functions? Because imrotate eventually calls imremap.

Carnë Draug <carandraug>
Project Member
Wed 26 Feb 2014 01:15:55 AM UTC, comment #1: 

For some reason I can upload a file. Here is a link to the image.

https://dl.dropboxusercontent.com/u/76158792/AI3c70.tif

I have not tried to replicate with a synthetic image.

Ian Journeaux <ijourneaux>
Tue 25 Feb 2014 10:17:16 PM UTC, original submission:  

I was able to narrow the problem I was having down to a call to imrotate.

AI3c=imread('AI3c70.tif');
AI3cr=imrotate(AI3c(1:3050,:),-5/3.14*180,'bilinear','crop');

I will upload the test image in a couple of minutes

Ian Journeaux <ijourneaux>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33173:  openmp-fix2.patch added by lostbard (3KiB - application/octet-stream)
file #33170:  openmp-fix.patch added by lostbard (2KiB - text/x-patch)
file #32984:  test-bug-41699.tar.gz added by carandraug (509B - application/gzip)

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by amro_octave (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by ijourneaux (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-12 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2016-05-06 rik5 Operating SystemMicrosoft Windows => Any
        Summaryimformats causes a segmentation fault on Windows when Octave exits => imformats causes a segmentation fault
    2016-05-04 rik5 Dependencies- => Depends on bugs #40689
    2016-05-04 rik5 Dependencies- => Depends on bugs #41074
    2016-04-22 jwe StatusFixed => In Progress
        Open/ClosedClosed => Open
    2016-04-08 rik5 StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2016-03-28 mtmiller Dependencies- => bugs #47555 is dependent
    2016-03-13 rik5 Dependencies- => bugs #47372 is dependent
    2015-06-03 mtmiller Releaseother => 4.0.0
    2015-05-01 mtmiller Dependencies- => bugs #44980 is dependent
    2015-02-24 fgnievinski Carbon-CopyRemoved 92640 => -
    2015-02-24 lostbard Attached File- => Added openmp-fix2.patch, #33173
    2015-02-24 rik5 StatusIn Progress => Confirmed
    2015-02-24 rik5 StatusNeed Info => In Progress
    2015-02-24 lostbard Attached File- => Added openmp-fix.patch, #33170
    2015-02-22 rik5 Carbon-Copy- => Added lostbard
    2015-02-05 mtmiller Dependencies- => bugs #40443 is dependent
    2015-02-05 mtmiller Dependencies- => bugs #41395 is dependent
    2015-02-05 mtmiller Summaryimread causes a segmentation fault on Windows with "clear all" or when Octave exits => imformats causes a segmentation fault on Windows when Octave exits
    2015-02-03 carandraug Attached File- => Added test-bug-41699.tar.gz, #32984
    2015-02-02 mtmiller Summaryimread causes a segmentation fault when exiting Octave => imread causes a segmentation fault on Windows with "clear all" or when Octave exits

    Back to the top


    Powered by Savane 3.5