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 (address@hidden)
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 (address@hidden)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f90ffce3418 in __GI_abort () at abort.c:89
#2 0x00007f9100b33e7c in panic (
address@hidden "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, address@hidden, 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 :)