The issue

Recently, a professor working at my Department reported me an issue with the plotepstex Matlab function running on an Ubuntu Linux 13.10 64 bit. This function had been working perfectly well on most Linux flavours so far, and that was the first time he tried to call it on a fresh Ubuntu 13.10 installation. The exact error was reported by the command eps2eps, as clearly shown below:

eps2eps crashing whilst being executed by the plotepstex matlab function.

Analysing the plotepstex Matlab function

According to the previous screenshot, a smart approach would be to have a look at the plotepstex Matlab function, in order to know how it was implemented. Thank God that was a simple Matlab file, not an internal Matlab function; otherwise I wouldn’t have had its sources!. First thing I decided to do was to prevent the script from deleting all the temporary files generated, this way I could be able to check them all. This is clearly shown in the next code-snippet, where all the calls to dos(sprintf(‘rm -rf %s’), TempName); had been commented:

Commenting the lines in charge of deleting the temporary files.

Running the script again inside Matlab left me with all these temporary files. I checked them one by one, to ensure they were correctly generated. The latex, DVI and Postscript files were fine; so I decided to run the eps2eps command outside Matlab by hand. Sort of trying to get the same error. Instead, the command ended its execution with no errors or warnings at all, and the final eps file was made:

~ eps2eps -dNOCACHE TEMP63242.ps fig7ba.eps

Clearly, the problem only shown up when running eps2eps inside a Matlab session. In fact, eps2eps was calling GhostScript, so the problem was exactly this one: whenever running the GhostScript interpreter from a Matlab session, it crashed.

It’s all about libraries

 Well, well… so, what is the difference between running anything inside a Matlab session and outside it? The environment, of course. Paths, libraries, and the like. Therefore, I had a look at the dynamic libraries the gs binary was using when being run inside Matlab, and when being run outside it:

~ ldd /usr/bin/gs > gs.outside.lst

To do that inside a Matlab session, I altered the plotepstex function slightly, so that I could run my own script and be able to output that information to a file:

Running my own script from the plotepstex Matlab in order to determine which libraries were being used by the gs command.

Finally, I checked their differences by running the diff command, and came out with this:

Differences between the libraries being used by gs in a Matlab session and outside it.

Well, that might be it. Matlab came with its own system libraries. Some of them were of different versions from the ones installed on the Ubuntu Linux 13.10 distro. That was the only apparent difference whilst running the gs command from a Matlab session. According to the error shown in the first screenshot, it was related to the fonts, somehow. And … what library from the previous list was quite related to the font system? libfreetype! Well well … I removed the Matlab version for that particular library and re-ran the plotepstex command inside Matlab:

Running plotepstex again, this time without using the Matlab libfreetype.so library.

As I thought, it worked. Problem solved, give me another :-P!