Archive

Archive for the ‘matlab’ Category

Matlab 2006a – Graphic callback causes Segmentation Fault

December 19, 2006 Leave a comment

I’ve recently had an issue with matlab running on an AMD Athlon 64 system which I thought I might share with you all, I submitted a bug report to the Mathworks site and thought I’d post it here for others who might be experiencing the same thing.

How can we assist you: I’m having a seg fault when using any figure buttons (ie zoom, move, etc). I’ve upgraded from R14 to R2006a and have moved the old directories out of the way. I’m running on Fedora Core 5 (I selected 3 in the above list as FC5 wasn’t available). Basically I’ll open a figure window (plot(cos([0:0.1:pi]))) and then press the zoom button (cursor changes) then when I click anywhere in the figure the application seg faults, I’ve cleared my pref files from under .matlab in my home directory and cleared my LD_LIBRARY_PATH environment variable as well. I’ve attached stack trace in matlab_crash_dump.23841

Expected Behavior: I expected the figure to zoom in, it seg faulted

I then got the following response from Mathworks

This is a known bug that affects the way MATLAB behaves on some Linux machines whenever a command is executed.

For some of our users, the following workaround has been useful:

1- Use setenv BLAS_VERSION atlas_P4.so (SUSE Linux 9.2 on Intel P4/Xeon)

If the above did not work, try:

2- If your glibc is not 2.3.5 try to updating to this.

Try this, and let me know if this resolves your issue.

As I said this isn’t an Intel system so I found the corresponding Athlon binaries for BLAS and used them instead, still no joy. I also tried every version of the binaries that shipped with 2006a but they all resulted in the same behaviour, so I sent back the following email to them.

thank you for your prompt reply. Unfortunately the BLAS_VERSION workaround doesn’t work for me, I’m running the 32-bit version of fedora core 5 on an AMD Athlon X2 64bit processor. Therefore I used

export BLAS_VERSION=/usr/local/matlab2006a/bin/glnx86/atlas_Athlon.so
matlab -nojvm -nosplash

cpu_id: x86 Family 15 Model 11 Stepping 2,
AuthenticAMD
libmwlapack: loading
/usr/local/matlab2006a/bin/glnx86/atlas_Athlon.so
libmwlapack: loading lapack.so

and the same thing happened when using the figure buttons, I am running glibc 2.4-4 and I’ve tried upgrading it to 2.4-11 which doesn’t seem to have any effect. I’m hoping you can provide some other suggestions for me as this is really annoying. A potential could be that I have installed another version of atlas in /usr/lib/sse2/ however I’ve removed all references to that directory from my LD_LIBRARY_PATH so I don’t know how it could interfere.

And got the following back

Hi Jamie,

This is a bug in MATLAB 7.2 (R2006a). To work around this issue, start MATLAB with the “nojit” flag by calling:

matlab -nojit

from the system terminal. This will disable the JIT in that MATLAB session.

Try this and let me know if this resolves the issue.

TaDa!!!! That was it, a simple -nojit added to the end of the command line and my problem is gone (JIT is the Just In Time compiler). Now we just have to persuade the university to upgrade to version 2006b.

Categories: ATLAS, BLAS, linux, matlab, R2006a

Matlab Licensing Issues (lmstat)

December 1, 2006 1 comment

Further to my previous post on compilation issues for matlab under Fedora Core 5, I found out that after getting my machine into a state where it was possible to perform the compilation, some bastard had come along and nicked the school’s one and only floating license for the Matlab Compiler… GRRR!!

License Manager Error -4.
Maximum number of users for Compiler reached.
Try again later.
To see a list of current users use the lmstat utility.

I called up the very uninformative techie who deals with this sort of stuff and was unable to get a straight answer on whether it was my crashed session of Matlab that had stolen the license or if someone else had nipped in and grabbed it while I was upgrading from R14 to R2006a. So I had to go and figure it out for myself. Turns out the lmstat utility doesn’t get automatically installed on linux systems and on windows systems only exists as a switch to another command. So the upshoot is if you want to know ‘who has the licence for matlab toolbox X?’ you had better have a windows installation around.

cd \bin\win32\
lmutil lmstat -c c:\MATLAB6p5\bin\win32\license.dat -a > licence.snapshot

Then just have a root around in that file for the appropriate toolbox.

Users of Compiler:  (Total of 1 license available)
"Compiler" v16, vendor: MLM
nodelocked license, locked to "ID=2202"
jamie jfedora.saivt.qut.edu.au /dev/pts/6 (v15) (bee-lics-l/27007 4704), start Wed 11/29 17:11
Categories: linux, matlab

Matlab R14 on Fedora Core 5 (FC5)

November 20, 2006 Leave a comment

I’ve been playing around with this all afternoon so I thought I’d just write up some notes on how I managed to get things working smoothly. My problem was that I was trying to compile a matlab library from m files that I wanted to call from C++ code, and the version of matlab I have was compiled with different versions of libstdc++.so than FC5 uses (gcc 4.1 with version 6 of libstdc++).

  • R13 compiled with gcc-2.95.3, libstdc++ 2.9 or below
  • R14 compiled with gcc-3.2.3, libstdc++.so.5 <== This is the version I'm using
  • R2006a compiled with gcc-3.4.5, libstdc++.so.6

So anyway I was following instruction from here, and was getting errors warning that libstdc++.so.5 may conflict with libstdc++.so.6. The end solution was to dual install the version of gcc that was used to build matlab R14, in this case 3.2.3. This isn’t the easiest thing in the world so the references I used was from the gcc faq. For convenience the process was as follows

  1. Download the source for gcc-3.2.3 (I used ftp://ftp.aarnet.edu.au/pub/gnu/gcc)
  2. Unzip / Untar the source package and change into the created directory
  3. ./configure --prefix=/usr/local/gcc3 --program-suffix=-3.2.3
  4. make bootstrap – I don’t know where the bootstrap option was recommended to me but it turned out to be invaluable as I got a bucket load of errors when trying to compile gcc-3.2.3 with gcc-4.1
  5. make install
  6. Then I had to create symlinks in /usr/local
    • cd /usr/local/gcc3
    • for i in *-3.2.3; do ln -s `pwd`/$i /usr/local/$i; done

Then I had to edit my mbuild options file [~/.matlab/R14/mbuildopt.sh] and change any reference to gcc or g++ to gcc-3.2.3 and g++-3.2.3 respectively. DONE.

UPDATE: This was an interesting exercise but I ended up simply updating my installation of Matlab rather than rebuilding all my libraries using the older compiler. It worked but too many things like xml parsing libraries and my biometrics libraries were compiled using gcc 4.1 so path of least resistance was just to update Matlab.

Categories: linux, matlab

Matlab – recursively add to the search path

September 29, 2006 Leave a comment

I couldn’t find a functional form to add a directory and all it’s subdirectories recursively to the path, so I wrote it myself. Here for your enjoyment!

function addDirPath(dirName)
% functional form of the add recursive subdirectories command
% add current directory
addpath(dirName);
% recursively add subdirectories
f=dir(dirName);
% skip the first two entries . & ..
for i=3:length(f)
  if f(i).isdir
    addDirPath([dirName filesep f(i).name]);
  end
end
Categories: code, matlab

DIY 3D Laser Scanner

July 26, 2006 Leave a comment

I’ve got to try this out sometime, and seeing as it fits nicely into my work with 3D face recognition I don’t even have to do it on my own time :)

Create your own super hi-tech 3-D laser scanner. Using just a laser pointer, wine glass, rotating platform, and a digital video camera, you can make accurate 3-D models of a object or person.

  1. Convert the video to an avi.
  2. Use an edge detection algorithm to find the location of the laser line.
  3. Reconstruct your 3-D model

Update: I’ve had trouble downloading the m-file so when I got it down I put it up here for anyone to grab.

Follow

Get every new post delivered to your Inbox.