bugGNU Octave - Bugs: bug #49718, Octave crashes on print/saveas etc...

 
 

bug #49718: Octave crashes on print/saveas etc when installed on a directory with parenthesis

Submitted by:  None
Submitted on:  Sun 27 Nov 2016 09:09:50 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: ConfirmedAssigned to: None
Originator Name: VeroOriginator Email: -unavailable-
Open/Closed: OpenRelease: 4.2.0
Operating System: Microsoft Windows

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 Jump to the original submission)

Thu 08 Dec 2016 01:37:09 PM UTC, comment #20:

Not that it fixes issues with running programs external to the mxe-octave paths, but what happens if we use the shortpath name instead for the octave path ?

Ie: adding to OctavePath section of octave.vbs:

John Donoghue <lostbard>
Project Member
Fri 02 Dec 2016 10:22:54 AM UTC, comment #19:

octave_popen eventually resolves to calls in sysdep.cc.

Since we are using different code on different systems, it is possible that _popen on Windows does not handle spaces well, while the popen command on Linux has no issues.

Rik <rik5>
Project Administrator
Fri 02 Dec 2016 10:20:20 AM UTC, comment #18:

I had a similar problem here with space characters:
https://savannah.gnu.org/bugs/?43534
"Octave shouldn't be installed in a path containing spaces. Just live with it."
(Here again in comment #3)

The fix was to prohibit space characters in the path which is checked at install time under Windows (when using the installer).
(Here again in comment #8)

Now there are other exemptions like parenthesis (#49718), German Umlaut-characters (#42036), French accents (#40239), Japanese characters (#44922) etc., ending in a common subset for POSIX portable filename characters.

Personally, I'm not happy with this. Whatever the operating system is allowing should be allowed, too.

At the end, there should IMHO be a clear design decision, either:

  • Octave accepts anything legal on the underlying OS for paths, installation folder, working folder, *.m file names, etc. (in every aspect of program usage)
  • Octave sticks to the lowest common denominator, the character set of POSIX "Fully portable filenames"

Anything in between might lead to an infinite loop with repeated, slightly deviating bug reports.

Armin Müller <arm_in>
Fri 02 Dec 2016 12:07:17 AM UTC, comment #17:

I put gs.exe in the directory

Using

I get

Inspecting variables in the m-file, pipeline{n} is

print.m is trying to protect the command by placing it in double quotes, but this may not be enough.

Lookin in gl2ps_print.cc, there is only one place where the phrase "internal pipe error" occurs which is when Octave fails to read from the temporary file containing gl2ps output and write to the pipe created with octave_popen.

The code that opens the pipe is

So we check immediately to see if the pipe was created successfully. Apparently, you can create the pipe but having any old command is fine because it doesn't really invoke it until something is written to the input side of the pipe.

The segfault is caused eventually by

This is a known problem. Because we have different threads running, when error() is called it seems to not pick up our installed error handler and return to the Octave prompt. Instead, it picks up the default which is exit().

Rik <rik5>
Project Administrator
Thu 01 Dec 2016 09:48:43 PM UTC, comment #16:

Not sure of how much it is, when when it crashes, bt on mine:

John Donoghue <lostbard>
Project Member
Thu 01 Dec 2016 09:38:53 PM UTC, comment #15:

moving gs.exe to a path with spaces in it and adding that path to octave causes octave to 'lockup' and/or crash for me.

John Donoghue <lostbard>
Project Member
Tue 29 Nov 2016 09:47:58 AM UTC, comment #14:

@Rik, comment #12: there is no system call in gl2ps. When we need to postprocess the generated eps, we copy the content of gl2ps temporary FILE into a file stream (pipe) after gl2ps has returned.
The stream is created before the call to gl2ps using octave_popen.

So it may also be the call to octave_popen that is failing when the name of the targeted external executable contains parents.

Pantxo Diribarne <pantxo>
Project Member
Tue 29 Nov 2016 01:20:03 AM UTC, comment #13:

According to comment #6, Octave crashes, fully exits and leaves behind an octave-workspace.

Btw, I did copy /usr/bin/epstool into "/tmp/Program Files (x86)/Octave/Octave-4.2.0/bin" and set PATH so that it would be called when I print to a .eps file. But still no crash here. I have not yet tried that with ghostscript.

Mike Miller <mtmiller>
Project Administrator
Tue 29 Nov 2016 01:15:20 AM UTC, comment #12:

From what I remember about a similar bug report, the crash is hard and is something to do with gl2ps being the one to invoke the system command.

Rik <rik5>
Project Administrator
Tue 29 Nov 2016 01:09:52 AM UTC, comment #11:

I agree with Mike that we should aim for being able to install in any directory as long as the name is a valid file name for the operating system.

As for why it could fail on Windows but not a GNU system, if it is a problem with an external dependency program like ghostcript, then my guess is that other program doesn't work properly when installed But that's not the case on the GNU system, where the external program is installed in /usr/bin (or similar) even when you install Octave in a directory like

Also, as Mike asked, what do we mean by "crash" here? Does Octave exit? Or does it just throw an error and fail to generate the desired output?

If Octave actually exits because of some external dependency that is doing the wrong thing, then we might still have a bug in Octave. Or it would be nice to fix the dependency to not fail in a way that causes Octave to crash.

If it is an external program like ghostcript that causes the trouble, then I'd be surprised if Octave crashes because of it. But if it is something like gl2ps that is linked with Octave, then I can see how it could easily cause Octave to exit with a segfault if it doesn't properly handle a non-portable filename.

John W. Eaton <jwe>
Project Administrator
Tue 29 Nov 2016 01:05:04 AM UTC, comment #10:

We could do some testing, but I imagine any shell special character such as

are going to be a problem.

Long term, it might be good to follow Mike's suggestion and figure out if there is a way to quote the path before we pass it to the shell.

Rik <rik5>
Project Administrator
Tue 29 Nov 2016 12:57:56 AM UTC, comment #9:

Checking for more characters and expanding the warning is probably sufficient to address this for now. I still think it would be a valid wishlist project for someone to work on. But I am unable to reproduce any of the problems described here in a directory containing spaces and parentheses on Debian. I have also copied the epstool binary into this private bin directory and set PATH appropriately, and still no problems.

If we want to be really stringent about the allowed characters, POSIX defines the set of portable filename characters as alphanumeric, period, underscore, and hyphen.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276

https://github.com/boostorg/filesystem/blob/develop/src/portability.cpp#L43

Mike Miller <mtmiller>
Project Administrator
Tue 29 Nov 2016 12:43:18 AM UTC, comment #8:

For comment #7, Easy enough to add to the installer check. There are probally some other characters that should not be used as well

John Donoghue <lostbard>
Project Member
Mon 28 Nov 2016 10:12:22 PM UTC, comment #7:

I'm adding John D. to the CC list since he does most of the work on the MXE installer.

There is a function for the Windows installer which checks for spaces in the name and alerts the user that this is a bad idea. A simple partial solution would be to extend this function to check for other questionable characters and throw up the same dialog box. The function is located in the MXE repository in the file tools/makeinst-script.sh.in.

The code itself is:

Rik <rik5>
Project Administrator
Mon 28 Nov 2016 07:29:08 PM UTC, comment #6:

I reinstalled Octave to C:\Program_Files_(x86)\Octave\Octave-4.2.0\ . Printing to an svg file did not cause Octave to crash. By crash I mean that Octave exits and produces the file octave-workspace to the working directory. Printing to an eps file (re)caused a crash.

I do not think it is necessary to prevent installations to directories with non-safe characters. However, a warning with the possibility to go back would be nice. The installer already warned about spaces, so I opted not to use them. However, the installer allowed to use parenthesis so, since it warned about a similar issue, I though it would be safe to use them.

/OP (also comment #4 is mine)

Anonymous
Mon 28 Nov 2016 07:07:07 PM UTC, comment #5:

For the OP - does printing to an svg file also cause Octave to crash? By "crash" you mean that Octave exits immediately, right?

The reporter has said that printing to an eps failed in the same way, but I see that even the eps format makes a call to the external epstool utility. Looks like printing to svg is the only one that doesn't use any external programs, only cat.

I agree that it has been suggested before to only install Octave in directories with safe character sets. Maybe I am in the minority but I think it should be possible to install Octave in a directory with any name, and I'm willing to test for and fix things that break because of that, assuming I'm able to reproduce the error on a GNU system.

Mike Miller <mtmiller>
Project Administrator
Mon 28 Nov 2016 07:00:51 PM UTC, comment #4:

The default install directory was C:\Octave\Octave-4.2.0\, which I chose not to use. The installer did not allow installing into "C:\Program Files (x86)\Octave\Octave-4.2.0\" due to spaces in the directory name. However, it did allow installing to the directory C:\Program_Files_(x86)\Octave\Octave-4.2.0\ .

I used the default graphics toolkit, which seems to be qt.

I think a safe way would be to raise a note about possible problems during the installation if the installation directory contains questionable characters.

Anonymous
Mon 28 Nov 2016 06:41:24 PM UTC, comment #3:

The reporter is running Microsoft Windows. From what I remember, this issue has happened before and it isn't Octave's problem per se. It is the fact that when printing we use gl2ps to get to an intermediate format of eps, and then use ghostscript to further transform the intermediate into the final output format. It is the sub-process call out to a shell to invoke ghostscript which I believe has problems.

The simplest solution has always been to just install Octave in a directory without whitespace or any other questionable characters. That's why I'm interested in whether our installer is now defaulting to installing Octave in an incorrectly named directory. It shouldn't do that, but if the user manually selected an install directory then we would have to honor that choice.

Rik <rik5>
Project Administrator
Mon 28 Nov 2016 06:03:21 PM UTC, comment #2:

FWIW, this works for me on Debian, if I install Octave 4.2.0 into "/some/directory/Program Files (x86)/Octave/Octave-4.2.0", both spaces and parentheses in the directory name. I can print figures and run the full test suite with no problems.

Only one test fails, "test doc", I'll fix that one shortly if it's simple enough.

Mike Miller <mtmiller>
Project Administrator
Mon 28 Nov 2016 05:30:10 PM UTC, comment #1:

Did the Octave installer default to the directory

or did you select the directory containing "_(x86)"?

Also, what graphics toolkit were you using? If one of the OpenGl toolkits (qt or fltk), does it work if you use gnuplot?

Rik <rik5>
Project Administrator
Sun 27 Nov 2016 09:09:50 PM UTC, original submission:

I installed Octave 4.2 using the installer to C:\Program_Files_(x86)\Octave\Octave-4.2.0\ and tried to print a figure with no luck. I tested printing as eps, png and pdf. I tried "save as" from the figure menu as pdf. Octave crashed every time.

I uninstalled the program, reinstalled it to C:\Program_Files\Octave\Octave-4.2.0\ and replotted with success (tried only png with print -command).

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by arm_in (Posted a comment)
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by lostbard (Posted a comment)
  • -unavailable- added by rik5
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by None (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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 28 Nov 2016 10:12:22 PM UTCrik5StatusNeed Info=>Confirmed
      Carbon-Copy-=>Added lostbard
    Mon 28 Nov 2016 05:30:10 PM UTCrik5StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1