bugGNU Octave - Bugs: bug #51994, strange path corruption when path...

 
 

bug #51994: strange path corruption when path is changed in a script or unit test

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Mon 11 Sep 2017 10:49:45 PM UTC  
 
Category: InterpreterSeverity: 4 - Important
Priority: 5 - NormalItem Group: Unexpected Error
Status: FixedAssigned to: Mike Miller <mtmiller>
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Wed 20 Sep 2017 10:05:52 PM UTC, comment #4:

I think this is fixed with the following change on default

https://hg.savannah.gnu.org/hgweb/octave/rev/34506e4e3b04

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Wed 20 Sep 2017 08:18:51 PM UTC, comment #3:

Ok, this has something to do with the way the load path is stored differently between stable and default and the side-effects of the builtin '__pathorig__' function.

Here is the simplest test case I can come up with to demonstrate this weird behavior

The underlying difference is due to 'pathdef', and the underlying internal function '__pathorig__', altering the load path.

In previous versions of Octave, when running out of the build tree, 'pathdef' returned an empty string and did not alter the load path. In the default version, it returns what the default path would be if Octave were already installed. And if 'make install' has already been run, those directories are actually added to the load path. This results in the wrong copy of '__have_gnuplot__' being called when the PKG_ADD files are processed.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Wed 13 Sep 2017 11:54:17 PM UTC, comment #2:

I made some changes to the unit tests that modify the load path to make them safer

https://hg.savannah.gnu.org/hgweb/octave/rev/2932a325930c

This works around the underlying issue by using path() instead of rmpath(). I will try to keep looking into this to see whether the original underlying problem needs to be addressed.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Tue 12 Sep 2017 01:31:46 AM UTC, comment #1:

I can work around this in one of two ways:

1. Don't run 'make install', or delete all files that were already installed by 'make install' for this build of Octave.

2. Change the test in scripts/miscellaneous/run.m so that it does not call addpath/rmpath.

There is another test, test/bug-38691/bug-38691.tst (see bug #38691) that also calls addpath/rmpath that may also be problematic (except that it occurs closer to the end of the test suite so there is less chance of it messing something up).

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Mon 11 Sep 2017 10:49:45 PM UTC, original submission:

When running the full test suite under a minimal environment, I noticed this strange behavior. It took me a while to narrow it down to a small reproducible test case, and I'm still not sure I've captured it well. But I can reproduce with the following (either as a script or in the interpreter)

I can only reproduce this error when I've built Octave and run 'make install', but I am still running Octave out of the build directory. If I haven't run 'make install' yet, I get no error, but I do get a much different result from the 'pathdef' function than normal. If I run the actual installed Octave I get no error, everything works fine.

The actual legitimate use case where this error comes up is

and at this point the test suite just exits, never finishes the fixed test scripts. This is a very realistic thing to do on a headless build box.

Some tests run which bring up gnuplot figures. The test case for the 'run' function calls 'addpath' and 'rmpath'. And then the test cases for 'pathdef' and 'savepath' fail. And by the time it gets to bc-overloads.tst it can't even locate the file in its load path, and the test function exits with an error.

I cannot reproduce this on the stable branch, this looks like new behavior.

As a workaround, maybe we shouldn't have unit tests that modify the load path. I'll see if removing all of those commands fixes this for me also.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.

 

(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 mtmiller (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 20 Sep 2017 10:05:52 PM UTCmtmillerStatusPostponed=>Fixed
      Open/ClosedOpen=>Closed
    Wed 13 Sep 2017 11:54:17 PM UTCmtmillerStatusNone=>Postponed
      Assigned toNone=>mtmiller

    Back to the top


    Powered by Savane 3.1-cleanup1