bugGNU Octave - Bugs: bug #40443, MinGW: Octave crashes on exit...

 
 

bug #40443: MinGW: Octave crashes on exit after GraphicsMagick tests

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 01 Nov 2013 09:01:49 AM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Duplicate Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 05 Feb 2015 06:12:00 AM UTC, comment #26: 

I just found this older bug report that has been inactive for a while. In the meantime, bug #41699 was reported and further progress has been made on fixing this error there. Closing as a duplicate.

Mike Miller <mtmiller>
Group Member
Thu 28 Nov 2013 12:09:53 AM UTC, comment #25: 

I'm attaching a backtrace from gdb on the MinGW side.  It matches jwe's stack.trace file with the crash occurring in the erase_scope() routine just as before.

(file #29721)

Rik <rik5>
Group administrator
Wed 27 Nov 2013 10:33:18 PM UTC, comment #24: 

For the record, I don't have that problem with my MSVC-compiled octave (based on afeb233ea443).

Michael Goffioul <goffioul>
Wed 27 Nov 2013 06:26:54 PM UTC, comment #23: 

I've narrowed it down to a simple one line function call.


octave-cli.exe
octave-cli.exe:1> imread ("x y z")
warning: your version of GraphicsMagick limits images to 8 bits per pixel
error: imread: cannot find x y z
error: called from:
error:   C:\Documents and Settings\Rik\My Documents\Octave\octave-2013-11-26-18-45\share\octave\3.7.
7+\m\image\private\__imread__.m at line 56, column 5
error:   C:\Documents and Settings\Rik\My Documents\Octave\octave-2013-11-26-18-45\share\octave\3.7.
7+\m\image\private\imageIO.m at line 64, column 26
error:   C:\Documents and Settings\Rik\My Documents\Octave\octave-2013-11-26-18-45\share\octave\3.7.
7+\m\image\imread.m at line 107, column 30
octave-cli.exe:1> exit

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


Actually, I tested imread with a proper image file and it correctly reads the file, but also segfaults when using exit.

It would seem that any command that initializes the GraphicsMagick library eventually causes a segfault at exit.

Rik <rik5>
Group administrator
Wed 27 Nov 2013 06:14:10 PM UTC, comment #22: 

Ups, sorry. I'm running Debian. I didn't notice it was a windows specific bug, only noticed the GM. Sorry about the noise.

Carnë Draug <carandraug>
Group Member
Wed 27 Nov 2013 06:10:01 PM UTC, comment #21: 

Carne, are you running on MinGW?  Was your version a native build or cross-build with MXE?

Rik <rik5>
Group administrator
Wed 27 Nov 2013 06:06:05 PM UTC, comment #20: 

I can't reproduce this on my system (cset 4138a7f80779)


$ octave --no-gui
octave:1> test imformats
PASSES 4 out of 4 tests
octave:2> exit

$ gm version
GraphicsMagick 1.3.18 2013-03-10 Q32 http://www.GraphicsMagick.org/
[...]


Carnë Draug <carandraug>
Group Member
Wed 27 Nov 2013 05:37:27 PM UTC, comment #19: 

Can you narrow it to a specific Octave function that calls graphics magick so we can trigger it outside of the test framework?  Or is it somehow related to the way the test is set up and run?

John W. Eaton <jwe>
Group administrator
Wed 27 Nov 2013 05:33:36 PM UTC, comment #18: 

I've found a reproducible crash for this bug.  It does not depend on having a read-only octave_hist file.  The problem seems to be in the Graphics Magick library.


octave-cli.exe
octave-cli.exe:1> test imformats
warning: your version of GraphicsMagick limits images to 8 bits per pixel
PASSES 4 out of 4 tests
octave-cli.exe:2> exit

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


Rik <rik5>
Group administrator
Tue 26 Nov 2013 05:19:37 PM UTC, comment #17: 

It sounds like the problem is in the symbol table and the scoping of variables and functions.  Given that the test suite does lots of strange things like eval'ing temporary functions into existence, using nested functions with unwind/protect blocks, etc. I'm not surprised that it provokes these kinds of things.

Rik <rik5>
Group administrator
Mon 25 Nov 2013 02:09:27 PM UTC, comment #16: 

You probably already have this in the picture; but ever since Rik's comment #8 I have the feeling that the segfault may be largely unrelated to the non-writable history file.

It turns out the crash occurs irrespective of the read-only status of the history file (the observation in comment #4 in hindsight does not invalidate this assumption.) Just running _run_test_suite_ suffices to provoke the crash on closing Octave on my WinXP box.

So, the whole read-only octave_hist issue seems to be a red herring as far as the crash/segfault is concerned (although the uninformative error message was real).

My strategy would be to break up the tests in _run_test_suite_ in sections and then by narrowing down try to find out which test / tested function sets the stage for the crash. Do you think this would be a good strategy?
(FYI I've already ignored & removed the jit.tst file in my tests for this bug, as the jit tests are known to crash MinGW Octave w/o invoking Ctrl-d - bug #40608.)
Anyway I won't have time for that until next weekend.


As to the fixes:
Of course your changeset works, but in the GUI the message just flashes by for .1 second before Octave disappears from sight.
Could there be some timer, of "Press <return>" statement, so that one has a chance to read the error message before Octave finally closes?

Philip Nienhuis <philipnienhuis>
Group Member
Mon 25 Nov 2013 03:44:19 AM UTC, comment #15: 

The stack trace I was able to get is attached.  It's crashing in the octave_user_function destructor in the call to symbol_table::erase_scope.  There's an ominous comment just before that line:


// FIXME: this is really playing with fire.


I guess we need to find out why this is crashing.  Longer term, we probably need to find a better way to deal with function scope information.


(file #29702)

John W. Eaton <jwe>
Group administrator
Mon 25 Nov 2013 03:11:07 AM UTC, comment #14: 

I started Octave with gdb and ran the test suite and it looks like it's crashing in the symbol_table::cleanup function.  I don't know why yet, or preciesely where since I'm using the stripped libraries that the mxe-octave mk-dist script creates.  I'll try again without stripping and see if I get better info.

John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 10:33:15 PM UTC, comment #13: 

Lots of questions :-)

(I wrote "-again!-" because I felt the discussion was tending towards a "crash/no crash" direction, rather than to how to provide more info to the user.)

I don't know if I can try the fix before Wednesday (busy week ahead). I'll pull in a minute + start build procedure in the hope I have a new build tomorrow morning.

On WinXP:

>> history_file
ans = C:\Home\Philip\.octave_hist
>> system ('attrib C:\Home\Philip\.octave_hist')
A          C:\Home\Philip\.octave_hist
ans = 0

and a MinGW shell says:
-rw-r--r--  1 Philip Administrators   31784 Nov 24 21:33 .octave_hist

On Win7:

>> history_file
ans = C:\Users\Philip\.octave_hist
>> system ('attrib C:\Users\Philip\.octave_hist')
A          C:\Users\Philip\.octave_hist
ans = 0

and a MinGW shell says:
-rw-r--r--  1 Philip Administrators   32638 Nov 24 22:46 .octave_hist

On both systems the file was preexisting (as I've been using Octave a long time there).

I suspect the actual problem for octave_hist to become read-only lies in the fact that $USERPROFILE (or %USERPROFILE%) isn't the best place for program settings. On Windows that had better be in %APPDATA%\Octave.
I filed a bug report about that (next up, bug #40444).

The crash happens in both GUI and CLI, but most "reliably" on Windows 8. That said, Win8 is the most picky towards ALL programs I try to run on it, not just Octave.

Rik suggested to first run _run_test_suite _ before exiting.

Tonight I have no more time to try in cmd32 & GUI.
MSYS is here: (after setting octave_hist read-only):

octave-cli.exe:2>__run_test_suite__
:
 <Ctrl-D>
octave-cli.exe:3> error: Permission denied
error: ignoring octave_execution_exception while preparing to exit
0x66A2CE40 (0x06D65C08 0x06C0156C 0x00000011 0x66CB31E8), _ZN5ArrayIdED2Ev() + 0x10 bytes(s)
0x06D55180 (0x66AB8620 0x00000000 0x00000000 0x66C932E8) <unknown module>
0x66A1DBC0 (0x08798B1C 0x355801C7 0x6F8366CB 0x31750108), _ZN5ArrayI12octave_valueED0Ev
0xEC835356 (0x00000000 0x00000000 0x00000000 0x00000000) <unknown module>
panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Philip@DeskPRN /x/octave/octave-377+_MXE/bin


Philip Nienhuis <philipnienhuis>
Group Member
Sun 24 Nov 2013 07:37:49 PM UTC, comment #12: 

Yes, obviously Octave shouldn't crash when exiting.  There's no need to write things like "-again!-".

I checked in the following changeset to improve the messages:

  http://hg.savannah.gnu.org/hgweb/octave/rev/260b44c0ed69

Since I could not read the message when running the GUI, I started trying to diagnose the problem by running octave-cli from the Windows and msys command shells.

On my system, I get a different value for history_file if I run Octave in the msys shell or from the Windows command shell, presumably because the value of $HOME is different for each of these.

I didn't see the message when running in the msys shell.

Running Octave in the Windows command shell, I saw the message.  For me, hisotry_file was c:\Users\jwe\.octave_hist and that file did not exist and c:\Users\jwe had permissions dr-xr-xr-x.

Then I saw some strange results after I tried to fix permissions.  Once I created the .octave_hist file I no longer saw the message, even after removing .octave_hist again and resetting the home directory permissions.  Very odd.

What does history_file return on your system?

Does that file exist prior to running Octave?

What are the permissions for the file (if it exists) and the directory where it is supposed to be found?

I wasn't seeing any signs of a crash with or without the GUI.  Do you see the crash with the GUI?  What about with octave-cli when using the Windows command shell?  When using the msys shell?

John W. Eaton <jwe>
Group administrator
Sun 24 Nov 2013 11:02:55 AM UTC, comment #11: 

My main point -again!- is that Octave:
1. should give more info on exactly what "permission is denied"
2. shouldn't segfault/crash if octave_hist turns out to be read-only (be it with or w/o running _run_test_suite_.m)

Otherwise you're right, with yesterday's build (Nov 23rd) I do not see it anymore on WinXP (and Win7, see below). I'll have to try on Win8 (at work) as well, that's where I hit this the most (comment #9 referred to Win8), but I'll be at my own desk next Wednesday at the earliest.

I just saw that on my Win7 box the file:
C:\Users\Philip\.octave_hist
had been set to read-only again. After wiping the read-only flag Octave behaves "as it should".
I'm puzzled as to which process is doing this - I had reset it to writable a while ago, even several times.

My builds are usually not much older than 2 days. I doubt whether this read-only octave_hist has anything to do with mxe itself; I've hit this before with 3.6.x and 3.2.x MinGW builds.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 23 Nov 2013 11:22:09 PM UTC, comment #10: 

Are you using the newest version for the mxe build? I remember that I had a lot of trouble concerning paths and permissions with an mxe build from the beginning of November (around 4th or so) which have disappeared in a build from November 11th. I am using it on in GUI mode a regular basis on different computers and have not encountered problems.

Torsten Lilge <ttl>
Group Member
Sat 23 Nov 2013 08:19:15 PM UTC, comment #9: 

Thanks for revisiting this bug.

In the mean time I found out that perhaps the issue isn't a read-only history file. I've carefully checked, and the history file is writable.
Maybe there is some race condition involved? Could it be that some write routines, or multiple threads, are in each other's way?

Philip Nienhuis <philipnienhuis>
Group Member
Sat 23 Nov 2013 07:01:23 AM UTC, comment #8: 

I devised a way to make this repeatable.  If I start an Octave session under windows and then immediately exit I get the warning about Permission denied, but no segfault.  If I execute _run_test_suite_ and then exit I get the segfault.

Rik <rik5>
Group administrator
Mon 18 Nov 2013 12:46:37 PM UTC, comment #7: 

FTR, here's what I get on Windows 8 after pressing Ctrl-D


octave-cli.exe:2> error: Permission denied
error: ignoring octave_execution_exception while preparing to exit
0x66A2C510 (0x0028FAE0 0x00000001 0x0028FFC4 0x74C1C265), _ZN5ArrayIdED2Ev() + 0
x10 bytes(s)
panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete


Philip Nienhuis <philipnienhuis>
Group Member
Mon 04 Nov 2013 10:52:21 PM UTC, comment #6: 

No segfault - you mean in any case not on Linux.
It does (seem to?) crash on Windows - that is, I get the usual Windows error message for crashing proggies with the choice of "Searching for solutions" (or reporting to M$, I forgot) or "Closing the program".

It could well be that Linux is a bit more robust (I don't doubt that anyway).

A thing that is in favor of your "no segfault" finding is that when running in gdb I see no segfaults or crashes either. I already noted that in comment #4.

In any case, segfault or not, I think it is desirable that unwary users are told exactly what "permission" is "denied". The current error message is uninformative and unhelpful.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 03 Nov 2013 11:22:11 PM UTC, comment #5: 

The error sequence appears to work on Linux.

I started Octave and then used Ctrl-Z to suspend it.  While Octave was suspended I did 'chmod -w ~/.octave-hist' to make the history file unwriteable.  Then I resumed Octave and did 'exit'.  I get


error: Permission denied
error: ignoring octave_execution_exception while preparing to exit


So the error is recognized, but then ignored.  There is no segfault.

Rik <rik5>
Group administrator
Fri 01 Nov 2013 05:00:00 PM UTC, comment #4: 

Done (bug #40444).

Additional info:
Yesterday evening I ran Octave in a debugger in a MinGW shell to get a backtrace; however to my surprise I saw no crash happening.
Apparently gdb catches it, or I overlooked it, or maybe there's a bug in MinGW gdb.

As to bug # 36477:
I peeked at the XDG specs; while probably superior they appear quite convoluted to me.
But yes I agree that also the root of my Linux home folder is a big mess with loads of .files and .subdirs. I often use mc (acronym of Midnight Commander IIRC) for navigating, I always have to scroll three pages of hidden stuff down before I get to the 3 or 4 'real' subdirs.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 01 Nov 2013 03:15:00 PM UTC, comment #3: 

You might also want to look at/compare bug #36477, which is a feature request to use the freedesktop.org standard for config and history files on *nix. I don't know if that would help on Windows, but it could be made part of the same effort to address both types of systems at once.

Mike Miller <mtmiller>
Group Member
Fri 01 Nov 2013 02:48:19 PM UTC, comment #2: 

Yes, please file a second bug report for which directory to file the .octave_hist file in.  That is a "Feature Request" rather than a "Crash" which needs more immediate attention.

Rik <rik5>
Group administrator
Fri 01 Nov 2013 12:37:17 PM UTC, comment #1: 

Indeed, a read-only .octave_hist was the culprit.

(I am sure I didn't manually set it to read-only. A wild guess is that it happened when I had several Octave sessions running simultaneously.)
I also found an .octave_hist file in the root of my system drive (C:\). No idea how it got there.

Anyway, I think Octave should not trust blindly that history & config files are always writable.
If there is a mechanism to catch write attempts to read-only files (I assume that's the case), it failed when writing the history file on both of my systems.


As an aside:
Presently Octave writes config & history files to the "root" of the user profile, as customary on *nix.
From what I know, on Windows the root of the user profile is mainly used by the system and not really intended for users or user programs.
On Windows systems, software settings etc. are supposed to go to program-specific subdirs in the "Application Data" subfolder in the user profile; it can be obtained by the environment string APPDATA. (e.g., getenv ("APPDATA") on my win7 box gives  'C:\Users\Philip\Application Data\Roaming\Octave')
I think it would be better if Octave for Windows systems complies to this. Shall I open a separate feature request for this?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 01 Nov 2013 09:01:49 AM UTC, original submission:  

Upon exit, MinGW builds (mxe-cross-built) yield the following error message:

octave-cli:2> error: Permission denied
error: ignoring octave_execution_exception while preparing to exit
panic: Segmentation violation -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete


(also reported here:
http://octave.1599824.n4.nabble.com/Problems-with-the-Windows-build-tc4658593.html#a4658641  )

I now see after restart that the history hasn't updated, so this exit crash does affect some functionality.

Now I've seen a similar-looking issue before; in that case it had to do with write permissions on the (location of the) history file. It was a bit sneaky in the sense that unwary users couldn't know what the actual issue was.

But whatever the underlying issue, Octave shouldn't crash, not even on exit, but rather catch the issue and somewhat politely suggest the user what to do.

I'll investigate later today (no time now) what the current underlying issue could be and report back.

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #29721:  bt_imread.log added by rik5 (7KiB - text/x-log)
file #29702:  stack-trace added by jwe (5KiB - application/octet-stream)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

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

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-05 mtmiller StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #41699
    2014-08-03 rik5 SummaryMinGW: Octave crashes on exit after GrahicksMagick tests MinGW: Octave crashes on exit after GraphicsMagick tests
    2013-11-28 carandraug Carbon-CopyRemoved carandraug -
    2013-11-28 rik5 Attached File- Added bt_imread.log, #29721
    2013-11-27 rik5 SummaryMinGW: Octave crashes on exit when octave history file is read-only MinGW: Octave crashes on exit after GrahicksMagick tests
        Carbon-Copy- Added carandraug
    2013-11-25 jwe Attached File- Added stack-trace, #29702
    2013-11-08 rik5 SummaryMinGW: Octave crashes on exit MinGW: Octave crashes on exit when octave history file is read-only
    2013-11-01 philipnienhuis CategoryNone Libraries

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code