Octave type argument error calling mxGetField

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave type argument error calling mxGetField

Hans Peschke
Hello everybody out there using and developping octave!
 
I would love to port some matlab code to run with octave.  Beside some
unproblematic m-files, there is a C struct type coming along with
delete.c, subasgn.c and subsref.c in its @Type directory, each
implementing a mexFunction(..), handling syntax and basic access for
the types instances.

As I'm new to such sophisticated matlab and octave programming, I
don't know wether the approach taken here is the right way or whether
it's compatible with octave.

The problem is, that as soon as a call to the function mxGetField
occurs (triggered for example by an acces to a field of an instance of
the type, resulting calling the @Type/subsref.c:mexFunction(..) )
octave stumbles over it, called in the following manner

void mexFunction(
  int nlhs,       mxArray *plhs[],
  int nrhs, const mxArray *prhs[]
  )
{
  mxArray *ptr;
  ..
  ptr = mxGetField(prhs[0], 0, "handle");
  ..
}

which results in the following octave (version 3.8.1 shipped in
lubuntu 14.10) error:

error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556

A debug session with gdb attached to the octave session results in the
following backtrace:

25        ptr = mxGetField(prhs[0], 0, "handle");
(gdb) n
Program received signal SIGABRT, Aborted.
0x00007f90ffce1d27 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f90ffce1d27 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f90ffce3418 in __GI_abort () at abort.c:89
#2  0x00007f9100b33e7c in panic (
    fmt=fmt@entry=0x7f9100e626f0 "impossible state reached in file '%s' at line %d") at corefcn/error.cc:743
#3  0x00007f9100619665 in mxArray_octave_value::request_mutation (
    this=<optimized out>) at corefcn/mex.cc:556
#4  0x00007f9100d115e3 in request_mutation (this=<optimized out>)
    at corefcn/mex.cc:460
#5  mxArray_octave_value::get_field_number (this=<optimized out>)
    at corefcn/mex.cc:462
#6  0x00007f9100d0ec33 in mxGetField (ptr=0x119af90, index=0,
    key=<optimized out>) at corefcn/mex.cc:2930
#7  0x00007f90eed8a18f in mexFunction (nlhs=8215, plhs=0x7f90ef785020,
    nrhs=6, nrhs@entry=2, prhs=0x7f90ef785010) at subsref.c:2
..

I digged through the calls in the octave source and tried to
understand what is going on. But I figured out, that octaves structure
and type system is currently far out of my experience-horizon in order
to resolve it alone.

Any help or suggestions would be very appreciated!
If you need any other info, feel free to ask :)
 
mrsep
 

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Octave type argument error calling mxGetField

Julien Bect
Le 13/12/2014 20:39, Hans Peschke a écrit :
Hello everybody out there using and developping octave!
 
I would love to port some matlab code to run with octave.  Beside some
unproblematic m-files, there is a C struct type coming along with
delete.c, subasgn.c and subsref.c in its @Type directory, each
implementing a mexFunction(..), handling syntax and basic access for
the types instances.

As I'm new to such sophisticated matlab and octave programming, I
don't know wether the approach taken here is the right way or whether
it's compatible with octave.

The problem is, that as soon as a call to the function mxGetField
occurs (triggered for example by an acces to a field of an instance of
the type, resulting calling the @Type/subsref.c:mexFunction(..) )
octave stumbles over it, called in the following manner

void mexFunction(
  int nlhs,       mxArray *plhs[],
  int nrhs, const mxArray *prhs[]
  )
{
  mxArray *ptr;
  ..
  ptr = mxGetField(prhs[0], 0, "handle");
  ..
}

which results in the following octave (version 3.8.1 shipped in
lubuntu 14.10) error:

error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556

A debug session with gdb attached to the octave session results in the
following backtrace:

25        ptr = mxGetField(prhs[0], 0, "handle");
(gdb) n
Program received signal SIGABRT, Aborted.
0x00007f90ffce1d27 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f90ffce1d27 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f90ffce3418 in __GI_abort () at abort.c:89
#2  0x00007f9100b33e7c in panic (
    fmt=fmt@entry=0x7f9100e626f0 "impossible state reached in file '%s' at line %d") at corefcn/error.cc:743
#3  0x00007f9100619665 in mxArray_octave_value::request_mutation (
    this=<optimized out>) at corefcn/mex.cc:556
#4  0x00007f9100d115e3 in request_mutation (this=<optimized out>)
    at corefcn/mex.cc:460
#5  mxArray_octave_value::get_field_number (this=<optimized out>)
    at corefcn/mex.cc:462
#6  0x00007f9100d0ec33 in mxGetField (ptr=0x119af90, index=0,
    key=<optimized out>) at corefcn/mex.cc:2930
#7  0x00007f90eed8a18f in mexFunction (nlhs=8215, plhs=0x7f90ef785020,
    nrhs=6, nrhs@entry=2, prhs=0x7f90ef785010) at subsref.c:2
..

I digged through the calls in the octave source and tried to
understand what is going on. But I figured out, that octaves structure
and type system is currently far out of my experience-horizon in order
to resolve it alone.

Any help or suggestions would be very appreciated!
If you need any other info, feel free to ask :)

Hello Hans,

I use MEX-files regularly but I've never come accross such a problem.

It would help if you could post some minimal code to reproduce the error.

@++
Julien




_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Octave type argument error calling mxGetField

Julien Bect
**** Please keep the mailing list in copy of your answers ****

Le 14/12/2014 13:08, Hans Peschke a écrit :
Am 14. Dezember 2014 09:08:44 MEZ, schrieb Julien Bect [hidden email]:
Le 13/12/2014 20:39, Hans Peschke a écrit :
Hello everybody out there using and developping octave!
 
I would love to port some matlab code to run with octave.  Beside some
unproblematic m-files, there is a C struct type coming along with
delete.c, subasgn.c and subsref.c in its @Type directory, each
implementing a mexFunction(..), handling syntax and basic access for
the types instances.

As I'm new to such sophisticated matlab and octave programming, I
don't know wether the approach taken here is the right way or whether
it's compatible with octave.

The problem is, that as soon as a call to the function mxGetField
occurs (triggered for example by an acces to a field of an instance of
the type, resulting calling the @Type/subsref.c:mexFunction(..) )
octave stumbles over it, called in the following manner

void mexFunction(
  int nlhs,       mxArray *plhs[],
  int nrhs, const mxArray *prhs[]
  )
{
  mxArray *ptr;
  ..
  ptr = mxGetField(prhs[0], 0, "handle");
  ..
}

which results in the following octave (version 3.8.1 shipped in
lubuntu 14.10) error:

error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556

A debug session with gdb attached to the octave session results in the
following backtrace:

25        ptr = mxGetField(prhs[0], 0, "handle");
(gdb) n
Program received signal SIGABRT, Aborted.
0x00007f90ffce1d27 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f90ffce1d27 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f90ffce3418 in __GI_abort () at abort.c:89
#2  0x00007f9100b33e7c in panic (
    fmt=fmt@entry=0x7f9100e626f0 "impossible state reached in file '%s' at line %d") at corefcn/error.cc:743
#3  0x00007f9100619665 in mxArray_octave_value::request_mutation (
    this=<optimized out>) at corefcn/mex.cc:556
#4  0x00007f9100d115e3 in request_mutation (this=<optimized out>)
    at corefcn/mex.cc:460
#5  mxArray_octave_value::get_field_number (this=<optimized out>)
    at corefcn/mex.cc:462
#6  0x00007f9100d0ec33 in mxGetField (ptr=0x119af90, index=0,
    key=<optimized out>) at corefcn/mex.cc:2930
#7  0x00007f90eed8a18f in mexFunction (nlhs=8215, plhs=0x7f90ef785020,
    nrhs=6, nrhs@entry=2, prhs=0x7f90ef785010) at subsref.c:2
..

I digged through the calls in the octave source and tried to
understand what is going on. But I figured out, that octaves structure
and type system is currently far out of my experience-horizon in order
to resolve it alone.

Any help or suggestions would be very appreciated!
If you need any other info, feel free to ask :)

Hello Hans,

I use MEX-files regularly but I've never come accross such a problem.

It would help if you could post some minimal code to reproduce the error.


Hello Julien,

Alright, I'm working on it ;)

But i doubt it would be very useful to post the code directly in an email, because there will be at least 5 files involved. Thus I'll upload it to a git repo, which should be more convenient to work with.

Hans


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Octave type argument error calling mxGetField

Julien Bect
Le 14/12/2014 14:29, Julien Bect a écrit :
Le 14/12/2014 13:08, Hans Peschke a écrit :
Am 14. Dezember 2014 09:08:44 MEZ, schrieb Julien Bect [hidden email]:
Le 13/12/2014 20:39, Hans Peschke a écrit :
Hello everybody out there using and developping octave!
 
I would love to port some matlab code to run with octave.  Beside some
unproblematic m-files, there is a C struct type coming along with
delete.c, subasgn.c and subsref.c in its @Type directory, each
implementing a mexFunction(..), handling syntax and basic access for
the types instances.

As I'm new to such sophisticated matlab and octave programming, I
don't know wether the approach taken here is the right way or whether
it's compatible with octave.

The problem is, that as soon as a call to the function mxGetField
occurs (triggered for example by an acces to a field of an instance of
the type, resulting calling the @Type/subsref.c:mexFunction(..) )
octave stumbles over it, called in the following manner

void mexFunction(
  int nlhs,       mxArray *plhs[],
  int nrhs, const mxArray *prhs[]
  )
{
  mxArray *ptr;
  ..
  ptr = mxGetField(prhs[0], 0, "handle");
  ..
}

which results in the following octave (version 3.8.1 shipped in
lubuntu 14.10) error:

error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556

[snip]
Hello Hans,

I use MEX-files regularly but I've never come accross such a problem.

It would help if you could post some minimal code to reproduce the error.


Hello Julien,

Alright, I'm working on it ;)

But i doubt it would be very useful to post the code directly in an email, because there will be at least 5 files involved. Thus I'll upload it to a git repo, which should be more convenient to work with.

Of course a git repo will do, but a zip would have been good enough :)


_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Aw: Re: Octave type argument error calling mxGetField

Hans Peschke-2
I wrote a minimal example which reproduces the error. You can grab it from the following git repo
 
git clone https://bitbucket.org/mrsep/minig.git

or download a zip file from this site:
https://bitbucket.org/mrsep/minig/downloads

It ships with a small compile script which you need to adapt to your environment (path to octave header files etc.)
and also with a short octave script (test.m) which reproduces the error

Please don't get confused with its uselessness, I just kept the structure of the original code and changed all names and removed all the other structs, methods and fields.
 
Gesendet: Sonntag, 14. Dezember 2014 um 14:34 Uhr
Von: "Julien Bect" <[hidden email]>
An: "Hans Peschke" <[hidden email]>
Cc: "help-octave Octave" <[hidden email]>
Betreff: Re: Octave type argument error calling mxGetField
Le 14/12/2014 14:29, Julien Bect a écrit :
Le 14/12/2014 13:08, Hans Peschke a écrit :
Am 14. Dezember 2014 09:08:44 MEZ, schrieb Julien Bect <julien.bect@...>:
Le 13/12/2014 20:39, Hans Peschke a écrit :
Hello everybody out there using and developping octave!
 
I would love to port some matlab code to run with octave.  Beside some
unproblematic m-files, there is a C struct type coming along with
delete.c, subasgn.c and subsref.c in its @Type directory, each
implementing a mexFunction(..), handling syntax and basic access for
the types instances.

As I'm new to such sophisticated matlab and octave programming, I
don't know wether the approach taken here is the right way or whether
it's compatible with octave.

The problem is, that as soon as a call to the function mxGetField
occurs (triggered for example by an acces to a field of an instance of
the type, resulting calling the @Type/subsref.c:mexFunction(..) )
octave stumbles over it, called in the following manner

void mexFunction(
  int nlhs,       mxArray *plhs[],
  int nrhs, const mxArray *prhs[]
  )
{
  mxArray *ptr;
  ..
  ptr = mxGetField(prhs[0], 0, "handle");
  ..
}

which results in the following octave (version 3.8.1 shipped in
lubuntu 14.10) error:

error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556

[snip]
Hello Hans,

I use MEX-files regularly but I've never come accross such a problem.

It would help if you could post some minimal code to reproduce the error.


Hello Julien,

Alright, I'm working on it ;)

But i doubt it would be very useful to post the code directly in an email, because there will be at least 5 files involved. Thus I'll upload it to a git repo, which should be more convenient to work with.

Of course a git repo will do, but a zip would have been good enough :)
 

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: Octave type argument error calling mxGetField

Julien Bect
Le 14/12/2014 20:47, Hans Peschke a écrit :
I wrote a minimal example which reproduces the error. You can grab it from the following git repo
 

or download a zip file from this site:
https://bitbucket.org/mrsep/minig/downloads

It ships with a small compile script which you need to adapt to your environment (path to octave header files etc.)
and also with a short octave script (test.m) which reproduces the error

Please don't get confused with its uselessness, I just kept the structure of the original code and changed all names and removed all the other structs, methods and fields.

Hello Hans,

Please answer *below* when you post on Octave's mailing list (i.e., use bottom-posting).

I have tried your test files (on Octave 3.9.0+ on Ubuntu 14.10 32 bits):

1) If I compile with your compile.sh script, Octave crashes as you describe.

octave:1> test
n = <class Number>
error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556
panic: Abandon -- stopping myself...

2) if I use instead the following instructions directly from octave:

cd lib
mex -c -I. Number.c
mex -c -I. Wrap.c

cd ../matlab
mex -I. -I../lib -D_MEASURE_ number_.c ../lib/Number.o ../lib/Wrap.o

cd ../@Number
mex -I. -I../lib -D_MEASURE_ subsref.c ../lib/Number.o ../lib/Wrap.o
mex -I. -I../lib -D_MEASURE_ subsasgn.c ../lib/Number.o ../lib/Wrap.o
mex -I. -I../lib -D_MEASURE_ delete.c ../lib/Number.o ../lib/Wrap.o
cd ..

then it doesn't crash. But I still get the following error message:

n = <class Number>
error: invalid index for class
error: called from:
error:   /home/bect/Sandbox/matlabOctave/essaiHansPeschke/minig/test.m at line 7, column 1


3) I have also tried with Matlab R2012a. I get this

>> test

n =

    Number object: 1-by-1

ans =

  1.2672e-314

Is it the expected ouput ?

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: Octave type argument error calling mxGetField

Hans Peschke-2
On 05.01.2015 13:31, Julien Bect wrote:> Hello Hans,
 >
 > Please answer *below* when you post on Octave's mailing list (i.e., use
 > bottom-posting).
 >
 > I have tried your test files (on Octave 3.9.0+ on Ubuntu 14.10 32 bits):
 >
 > 1) If I compile with your compile.sh script, Octave crashes as you describe.
 >
 > octave:1> test
 > n = <class Number>
 > error: octave_class::as_mxArray (): wrong type argument 'class'
 > panic: impossible state reached in file 'corefcn/mex.cc' at line 556
 > panic: Abandon -- stopping myself...
 >
 > 2) if I use instead the following instructions directly from octave:
 >
 > cd lib
 > mex -c -I. Number.c
 > mex -c -I. Wrap.c
 >
 > cd ../matlab
 > mex -I. -I../lib -D_MEASURE_ number_.c ../lib/Number.o ../lib/Wrap.o
 >
 > cd ../@Number
 > mex -I. -I../lib -D_MEASURE_ subsref.c ../lib/Number.o ../lib/Wrap.o
 > mex -I. -I../lib -D_MEASURE_ subsasgn.c ../lib/Number.o ../lib/Wrap.o
 > mex -I. -I../lib -D_MEASURE_ delete.c ../lib/Number.o ../lib/Wrap.o
 > cd ..
 >
 > then it doesn't crash. But I still get the following error message:
 >
 > n = <class Number>
 > error: invalid index for class
 > error: called from:
 > error: /home/bect/Sandbox/matlabOctave/essaiHansPeschke/minig/test.m at
 > line 7, column 1
 >
 >
 > 3) I have also tried with Matlab R2012a. I get this
 >
 >   >> test
 >
 > n =
 >
 >       Number object: 1-by-1
 >
 > ans =
 >
 >     1.2672e-314
 >
 > Is it the expected ouput ?
 >

Hello Julien,
I just played around a little with your compile.m script and experienced some
*very* strange behaviour, which I can not explain.

With your compile.m script I also could reproduce my original crash, but only
under a this strange circumstance:

./clean.sh
octave
cd path/to/minig
compile
 > ... the usual warnings
test
n = <class Number>
error: invalid index for class
error: called from:
error:   /path/to/minig/test.m at line 8, column 1

in a different terminal: vim compile.m
test
n = <class Number>
error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/mex.cc' at line 556
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Aborted (core dumped)

Thus the result of executing the test.m script depends on whether the compile
script is edited (only open, no changes done) with vim. There are maybe also
some other situations which strange outcome, but I conly could reproduce this case.
The next crazy thing is: when I quit vim in the other terminal, remove the
octave core dump, start octave, change to the minig directory and start test.m,
then it crashes again. But the object files and mex files didnt change.
The can be reset by cleaining all the object files with clean.sh. There is
something very strange going on here. Can you reproduce this behaviour?

I didnt test minig with Matlab 2012, once I tried it with matlab 2014, but it
crashed, I can try it tomorrow again.


In all the code in minig, there is one thing I don't understand at all, namely
the line in @Number/Number.m:26,27
n.handle = number_(arg0);
n = class(n, 'Number');

What is this handle thing. Are these Matlab handle classes then? I read
somewhere, that handle classes are not supported by octave. I mean number_ just
wraps it in a Wrap object, but what is this handle field about and what happens
in line 27?? Do you have an explanation for this?

Thanks a lot and happy new year :)
Hans Peschke

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: Octave type argument error calling mxGetField

Julien Bect
Le 07/01/2015 19:59, Hans Peschke a écrit :

> I just played around a little with your compile.m script and
> experienced some *very* strange behaviour, which I can not explain.
>
> [...]
>
> What is this handle thing. Are these Matlab handle classes then? I
> read somewhere, that handle classes are not supported by octave. I
> mean number_ just wraps it in a Wrap object, but what is this handle
> field about and what happens in line 27?? Do you have an explanation
> for this?

Hans,

I haven't tried to understand what your code is really supposed to do,
but here are a few remarks.


First, delete.c (line 16) uses mxSetField to modify prhs[0], thus
overriding the const specifier.

I don't think that prhs[0] is supposed to be modified (that why it's const).

If you want to modify it, it would probably be safer to use
mxDuplicateArray first, modify it, and then return the result as plhs[0].


Second, WrapNew is not defined in number_.c.

If you include Wrap.h, you will see that WrapNew expects a double and
you pass a double*.

I suggest changing WrapNew(value) to WrapNew(*value).


Third, "handle" has nothing to do with Matlab's "handle classes".

It is the name of a field in your structure (see Number.m).


@++
Julien

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave