32-bit MEX file (Fortran) works correctly, the same 64-bit MEX file causes "Segmentation Fault"
3 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
Hello everyone
I am working with a Fortran compiled MEX file in a Linux based 32-bit environment, and it works properly (*.mexglx file).
I need to work with that same code in a 64-bit environment, so I just re-compile the Fortran code in that machine, getting a *.mexa64 file. Well, this file gets a "Segmentation Fault". The Fortran code is the same, and Matlab did not complain when compiling with 'mex'.
The original code is just ordinary code, with some variable inputs and some variable outputs. It does not "interact" with anything else.
Does anyone know where the problem might be?
Thank you in advance.
Carlos
4 comentarios
Jan
el 1 de Jul. de 2011
@Carlos: It is really likly that there is a problem in the code. So please show us the relevant part of it.
Respuestas (7)
Friedrich
el 1 de Jul. de 2011
You have to be carefull with simply recompile the Fortran code on 64bit. The FORTRAN pre-compiler interprets the mwPointer differnt. The FORTRAN preprocessor converts mwPointer to INTEGER*4 when building binary MEX-files on 32-bit platforms and to INTEGER*8 on 64-bit platforms. So make sure you are using mwSize instead of some hardcoded INTEGER*4.
Without any code its hard to tell whats causes this crash. Please post some code which crashes if you need further help with this.
0 comentarios
Carlos Casanueva
el 1 de Jul. de 2011
1 comentario
Friedrich
el 1 de Jul. de 2011
i think for example this can be dangerous:
Extract input data from pointer prhs
in_ptr=mxGetPr(prhs(1))
call mxCopyPtrToReal8(in_ptr, fsin, alen)
Since in_ptr is an integer and not an mwPointer as it should arcording the documentation. Is this integer 32bit or 64bit in the compiled mex file? because when its 32bit it will crash since you call mxCopyPtrToReal8 on it which expects a 64bit variable. please modify your code that it matched the datatypes mentioned in the documentation.
Jan
el 1 de Jul. de 2011
What exactly is "integer" in your 64bit compiler? nrhs and nlhs must be "integer*4" for example. If they are "integer*8", the mex should crash.
1 comentario
James Tursa
el 1 de Jul. de 2011
A Fortran default integer is typically integer*4, even for 64-bit systems. It is likely that this is causing a pointer problem in the code.
James Tursa
el 1 de Jul. de 2011
A Fortran default integer is almost certainly an integer*4, even for 64-bit compilers. Compiler vendors typically do this so that older code that depends on a default integer being an integer*4 have a better chance of compiling and running correctly when they use their code on a 64-bit machine. However, this makes a default integer type unreliable to use for holding a pointer, and using it that way will almost certainly crash MATLAB. This is the EXACT problem that I was expecting to see in the code and why one should always use mwPointer for the pointer types and mwSize for the size types. Your code needs to be completely scrubbed and everything made consistent with regards to the API interface. If you want to see examples of this you can take a look at my Fortran 95 - MATLAB API interface submission on the FEX:
That being said, I haven't completely updated this submission for 64-bit yet. I have all of the coding done but haven't completed testing yet. Hopefully I will be able to upload it in the next week or so.
Another reason to take a look at my Fortran 95 submission is that it has routines to get Fortran pointers to the mxArray contents, so you don't need to use the clunky mxCopyReal8ToPointer and mxCopyPointerToReal8 routines at all.
0 comentarios
Helen
el 29 de Jul. de 2016
For more information, see Upgrade MEX-Files to Use 64-Bit API. In particular, see the section Update Fortran Source Code.
0 comentarios
Ver también
Categorías
Más información sobre Fortran with MATLAB en Help Center y File Exchange.
Productos
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!