bugGNU Octave - Bugs: bug #51960, mex or oct function in +package...

 
 

bug #51960: mex or oct function in +package directory that shadows Octave function only works once

Submitter:  Avinoam Kalma <avinoam>
Submitted:  Thu 07 Sep 2017 06:06:19 PM UTC
   
 
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  jwe
Originator Name:  Avinoam Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 10 Apr 2018 09:18:47 PM UTC, comment #10: 

It fixed the problem also for me (checked on Ubuntu).
Thanks!

Closing as fixed.

Avinoam Kalma <avinoam>
Group Member
Tue 10 Apr 2018 01:57:11 PM UTC, comment #9: 

I pushed the following changeset to stable and merged with default.

http://hg.savannah.gnu.org/hgweb/octave/rev/6f1fde568e46

It seems to fix the problem for me.  Can you confirm?

John W. Eaton <jwe>
Group administrator
Wed 14 Mar 2018 07:05:33 PM UTC, comment #8: 

Changing severity to 4-Important.
It does not allow to use external packages like mexopencv.

Avinoam Kalma <avinoam>
Group Member
Tue 02 Jan 2018 05:25:12 AM UTC, comment #7: 

Trying to see the origins of this problem, I have found that in 4.2.1, using the script desribed in the first comment, I get


>> temp.imread
my imread
>> temp.imread
my imread


This has been broken in http://hg.savannah.gnu.org/hgweb/octave/rev/551fa3879615


>> temp.imread
ans =

error: octave_base_value::print (): wrong type argument 'mex function'
>> temp.imread
ans =

error: octave_base_value::print (): wrong type argument 'mex function'


In http://hg.savannah.gnu.org/hgweb/octave/rev/2d4a7ae1f6cd appears difference between first and second call:


>> temp.imread
ans =

error: octave_base_value::print (): wrong type argument 'mex function'
>> temp.imread
ans =

error: octave_base_value::print (): wrong type argument 'user-defined function'


This has been reported in bug #51295, and has been fixed in http://hg.savannah.gnu.org/hgweb/octave/rev/ffd27f53fc79, but the fix is good for the first call, the second call finds the wrong function.

I hope this information will help to fix this bug.

Avinoam Kalma <avinoam>
Group Member
Fri 08 Sep 2017 05:56:29 PM UTC, comment #6: 

There are several extant bugs on 'which', 'classdef', and 'help' about the path not being worked out properly for classes and packages.

If you try 'which foo' for a package dir +foo you get


'foo' is a built-in function


This is clearly not right, but probably indicates something about why built-in functions generate a shadowed warning, but m-files don't.  I'm guessing that the path lookup is correct before the m-file in +foo has been executed.  When you request the function the very first time it has to be parsed, etc., and an entry in the symbol table is constructed.  My guess is that the 'file' variable, or whatever it is, in the constructed symbol table entry is incorrect.

Rik <rik5>
Group administrator
Fri 08 Sep 2017 04:07:01 PM UTC, comment #5: 

Changing the Operating System => Any.

Rik <rik5>
Group administrator
Fri 08 Sep 2017 03:43:50 PM UTC, comment #4: 

Hmm, this is a little bit tricky to reproduce. It has to be an oct or mex file in a +package directory that is overriding an m file function in Octave, not a builtin.

With +foo/size.oct there is no bug, because size is a builtin:


>> foo.size
warning: function ./+foo/size.oct shadows a built-in function
ans = This is my size function
>> foo.size
warning: function ./+foo/size.oct shadows a built-in function
ans = This is my size function


With +foo/imread.mex this bug occurs, because imread is an m file function:


>> foo.imread
my imread
>> foo.imread
error: Invalid call to imread.  Correct usage is:
...


And with +foo/which.oct it also occurs, because which is an m file function:


>> foo.which
ans = This is my which function
>> foo.which
error: Invalid call to which.  Correct usage is:
...


Mike Miller <mtmiller>
Group Member
Fri 08 Sep 2017 03:32:00 PM UTC, comment #3: 

I observed this on Debian with the current default branch. It does not affect 4.2.1 or the stable branch.

Mike Miller <mtmiller>
Group Member
Fri 08 Sep 2017 03:28:15 PM UTC, comment #2: 

Is this Windows specific, or are all versions of Octave affected?

Rik <rik5>
Group administrator
Thu 07 Sep 2017 07:26:23 PM UTC, comment #1: 

Confirmed here, both with mex and oct files. M file functions do not have this problem. Confirm also that it used to work in 4.2.1.

Calling "clear -f" allows the functions to work one time again.

Mike Miller <mtmiller>
Group Member
Thu 07 Sep 2017 06:06:19 PM UTC, original submission:  

An example:

Create the directory c:\data\+temp
And put there the flowing trivial function, called imread.cc


#include "mex.h"

void mexFunction (int nlhs, mxArray *plhs[],
             int nrhs, const mxArray *prhs[])
{
  mexPrintf ("my imread\n");

  return;
}


Now:


>> cd c:\data\+temp
>> mkoctfile -mex imread.cc
>> cd c:\data
>> temp.imread
my imread
>> temp.imread
error: Invalid call to imread.  Correct usage is:

-- [IMG, MAP, ALPHA] = imread (FILENAME)
-- [...] = imread (URL)
-- [...] = imread (..., EXT)
-- [...] = imread (..., IDX)
-- [...] = imread (..., PARAM1, VALUE1, ...)
….


In the first call, Octave recognizes temp.imread as the file in c:\data\+temp\imread.mex,
but in the second call, Octave calls its own imread.
 
This is a regression wrt 4.2.1.

Avinoam Kalma <avinoam>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 avinoam
  • -email is unavailable- added by amro_octave
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by avinoam (Submitted the item)
  • -email is unavailable- added by avinoam
  •  

    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
    2018-04-10 avinoam StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-04-10 jwe StatusConfirmed Ready For Test
    2018-03-29 avinoam Severity3 - Normal 4 - Important
    2018-01-02 avinoam Assigned toNone jwe
        Carbon-Copy- Added jwe
    2017-12-07 amro_octave Carbon-Copy- Added amro_octave
    2017-09-08 rik5 Operating SystemMicrosoft Windows Any
    2017-09-07 mtmiller StatusNone Confirmed
        SummaryProblem with function in +package directory that shadows Octave function mex or oct function in +package directory that shadows Octave function only works once
    2017-09-07 avinoam Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code