bugGNU Octave - Bugs: bug #55013, Deprecate kpse processing?

 
 

bug #55013: Deprecate kpse processing?

Submitted by:  None
Submitted on:  Mon 12 Nov 2018 09:54:52 AM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Rootsquash Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.1
Operating System:  GNU/Linux

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)

Fri 07 Dec 2018 05:40:04 AM UTC, comment #16:

The expansion of things like $VAR and {one,two} is done when using any of the kpse search functions. These are used by the directory_path class which is used by load_path and also the find_in_loadpath/find_in_path functions.

In any case, I think the complexity is not really needed. I removed it in the following changesets:

http://hg.savannah.gnu.org/hgweb/octave/rev/94fc8648f0fe
http://hg.savannah.gnu.org/hgweb/octave/rev/6e1a800dd365

John W. Eaton <jwe>
Project Administrator
Fri 16 Nov 2018 12:41:13 AM UTC, comment #15:

@jwe: When does this code get invoked? Is it only when path() is called? I don't feel like I know enough about when it is used to be able to say whether it should be removed or not. If you think we don't need it, however, then I'm fine with removing it. I'll check in the temporary fix on stable.

Rik <rik5>
Project Administrator
Thu 15 Nov 2018 11:39:46 PM UTC, comment #14:

Rik: Your patch seems fine for now.

Mike and Rik: Maybe we should strip out the code that does this fancy processing on PATH variables? Our users probably don't expect it and I don't think we really need it. If you agree, I can do it.

John W. Eaton <jwe>
Project Administrator
Thu 15 Nov 2018 10:44:59 PM UTC, comment #13:

Attached is a changeset that appears to solve the problem for me. Now when starting I get

This is the warning that is in kpse.cc and is supposed to be triggered.

It might make sense to add to the warning message because, while the code doesn't segfault anymore, I would have a hard time debugging this back to a typo in the PATH variable.

(file #45440)

Rik <rik5>
Project Administrator
Thu 15 Nov 2018 09:24:09 PM UTC, comment #12:

I can confirm Octave 4.0 through the current default branch crash when PATH contains a left curly brace without a matching right curly brace before the end of the string or the next colon delimiter.

Minimal example to crash for me:

Even though this is typically going to be a typo, and portable POSIX path names should not contain curly braces, it would be nice if Octave didn't crash on this in the environment.

If I actually do have a directory on my system, say "/tmp/weird{name/bin", this directory being in PATH will crash Octave.

Mike Miller <mtmiller>
Project Administrator
Thu 15 Nov 2018 08:05:15 PM UTC, comment #11:

Okay, I'm glad that this has an easy resolution.

Still, is there something simple we could do in Octave to catch this rather than segfault? If the issue is deep in the kpse code then I won't bother, but maybe if it is close to our code we could fix this.

Rik <rik5>
Project Administrator
Thu 15 Nov 2018 10:17:43 AM UTC, comment #10:

Wow, this is slightly embarrassing.

As jwe suspected, the error was due to my $PATH, specifically due to a typo that I never noticed before:

export PATH="{$PATH}:/home/rootsquash/.bin"

I have no idea if that's something a program should check for, but I know that I am quite happy to be able to use octave now, thank you very much!

Rootsquash

Root Squash <rootsquash>
Wed 14 Nov 2018 06:17:55 PM UTC, comment #9:

I agreed that the last bit of code that is still nominally Octave's is kpse_path_expand. We call it from within within octave::directory_path::init shown below.

I agree that knowing something about the PATH variable might be useful here.

Rik <rik5>
Project Administrator
Wed 14 Nov 2018 05:08:52 PM UTC, comment #8:

The failure appears to happen when searching the PATH for the gnuplot binary. But it looks like it happens before the actual search, while processing the PATH string from the environment. We probably shouldn't, but we still have some old code in there to expand things like ${VAR} or ${V1,V2}. Root Squash, what is the value of PATH on this system? If it doesn't contain anything to expand, then I'm not sure why this is failing. I'd need more info still, like the line number where the failure happens (from a copy of Octave built with debugging symbols), and possibly some variable values. What exactly is passed to kpse_path_expand?

John W. Eaton <jwe>
Project Administrator
Wed 14 Nov 2018 05:08:36 PM UTC, comment #7:

Dang, I was hoping for something simple.

Is the gnuplot executable installed on your system? Could you try installing it if is not?

Rik <rik5>
Project Administrator
Wed 14 Nov 2018 04:54:55 PM UTC, comment #6:

Line 37 already contains "gnuplot":

## Author: jwe

function [prog, args] = gnuplot_binary (new_prog, varargin)

mlock ();
persistent gp_binary = "gnuplot";
persistent gp_args = {};

Root Squash <rootsquash>
Wed 14 Nov 2018 04:46:39 PM UTC, comment #5:

It never rains, but it pours. This may be related to a recently filed bug #55023.

Could you locate the file gnuplot_binary.m on your system? It will be somewhere like PREFIX/share/octave/4.4.1/m/plot/util/gnuplot_binary.m.

Look at line 37 which begins

Is the assigned value "" as above or "gnuplot"?

Try changing the string to "gnuplot" if it is empty. Does that fix things?

Rik <rik5>
Project Administrator
Wed 14 Nov 2018 07:33:36 AM UTC, comment #4:

Done,

file should be attached.

The computer hardware should be fairly standard 64-bit x86 components: A core-i-something in an office-computer from one the big companies, only additions are: SSD, USB3 PCIe-card, old radeon-GPU and a bit more RAM.
No PowerPC-Stuff, no virtual OS or anything like that.

Root Squash <rootsquash>
Tue 13 Nov 2018 04:58:42 PM UTC, comment #3:

This is likely to be specific to your hardware, or possible to your OS ARCH. If this were a general problem we would have seen many reports earlier.

To debug, lets see if you can get a backtrace.A Install gdb if you haven't already done so. Then try this

When the gdb prompt comes up, type 'run'. Hopefully this aborts. When you return to the gdb prompt type 'bt' for backtrace and upload the trace file.

Rik <rik5>
Project Administrator
Tue 13 Nov 2018 11:03:54 AM UTC, comment #2:

Hi,

~ $ octave -f -q
terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr: __pos (which is 17) > this->size() (which is 16)
fatal: caught signal Aborted -- stopping myself...
Aborted (core dumped)

gives the same output.

Is there something else I should try, maybe strace or something similar?

Rootsquash

Anonymous
Tue 13 Nov 2018 01:11:09 AM UTC, comment #1:

Can you try starting Octave like this?

This is guaranteed not to load any configuration files and should help determine whether there is a problem with Octave or with some configuration specific to Arch.

Rik <rik5>
Project Administrator
Mon 12 Nov 2018 09:54:52 AM UTC, original submission:

On one of my Arch Linux installations, after installing octave, octave and octave-cli fail to start.
The system is up to date. ~/.octaverc and .config/octave/ don't exist.

user@host ~ $ octave
GNU Octave, version 4.4.1
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr: __pos (which is 17) > this->size() (which is 16)
fatal: caught signal Aborted -- stopping myself...
Aborted (core dumped)

This is obviously not the expected behaviour and probably not an Arch-problem: https://bbs.archlinux.org/viewtopic.php?id=241807

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45440:  kpse.cset added by rik5 (730B - application/octet-stream)
file #45422:  octave_gdb.txt added by rootsquash (6KiB - text/plain)

 

Depends on the following items: None found

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 rootsquash (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-07 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2018-11-16 rik5 SummaryTerminate on start ('std::out_of_range') => Deprecate kpse processing?
    2018-11-15 rik5 Attached File- => Added kpse.cset, #45440
        StatusInvalid => Patch Submitted
    2018-11-15 rik5 StatusNeed Info => Invalid
    2018-11-14 rootsquash Attached File- => Added octave_gdb.txt, #45422
    2018-11-13 rik5 CategoryNone => Interpreter
        Item GroupInstallation Failure => Segfault, Bus Error, etc.
        StatusNone => Need Info

    Back to the top


    Powered by Savane 3.3