[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave type argument error calling mxGetField

From: Julien Bect
Subject: Re: Octave type argument error calling mxGetField
Date: Sun, 14 Dec 2014 14:29:30 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

**** 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 <address@hidden>:
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/' 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/
#3  0x00007f9100619665 in mxArray_octave_value::request_mutation (
    this=<optimized out>) at corefcn/
#4  0x00007f9100d115e3 in request_mutation (this=<optimized out>)
    at corefcn/
#5  mxArray_octave_value::get_field_number (this=<optimized out>)
    at corefcn/
#6  0x00007f9100d0ec33 in mxGetField (ptr=0x119af90, index=0,
    key=<optimized out>) at corefcn/
#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 :)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]