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

 
 

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

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Fri 01 Nov 2013 09:01:49 AM UTC  
 
Category: LibrariesSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Crash
Status: NoneAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Open
Release: devOperating System: Microsoft Windows

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

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>
Project 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>
Project Member
Wed 27 Nov 2013 06:26:54 PM UTC, comment #23:

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

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>
Project 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>
Project 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>
Project Administrator
Wed 27 Nov 2013 06:06:05 PM UTC, comment #20:

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

Carnë Draug <carandraug>
Project 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>
Project 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.

Rik <rik5>
Project 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>
Project 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>
Project 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:

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>
Project 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>
Project 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:
and a MinGW shell says:
-rw-r--r-- 1 Philip Administrators 31784 Nov 24 21:33 .octave_hist

On Win7:
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):

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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>
Project 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 <ttl>
Project 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>
Project 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>
Project 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

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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

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

Rik <rik5>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member
Fri 01 Nov 2013 09:01:49 AM UTC, original submission:

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

(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>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 28 Nov 2013 12:47:19 AM UTCcarandraugCarbon-CopyRemoved carandraug=>-
    Thu 28 Nov 2013 12:09:53 AM UTCrik5Attached File-=>Added bt_imread.log, #29721
    Wed 27 Nov 2013 05:33:36 PM UTCrik5SummaryMinGW: Octave crashes on exit when octave history file is read-only=>MinGW: Octave crashes on exit after GrahicksMagick tests
      Carbon-Copy-=>Added carandraug
    Mon 25 Nov 2013 03:44:19 AM UTCjweAttached File-=>Added stack-trace, #29702
    Fri 08 Nov 2013 03:56:20 PM UTCrik5SummaryMinGW: Octave crashes on exit=>MinGW: Octave crashes on exit when octave history file is read-only
    Fri 01 Nov 2013 12:37:17 PM UTCphilipnienhuisCategoryNone=>Libraries

    Back to the top


    Powered by Savane 3.1-cleanup