mgieseki / dvisvgm

A fast DVI, EPS, and PDF to SVG converter
https://dvisvgm.de
GNU General Public License v3.0
306 stars 33 forks source link

dvisvgm 2.11.1 crashes on Solaris 11.4 #170

Closed joachim42 closed 2 years ago

joachim42 commented 2 years ago

We are using the latest version of TexLive, which includes dvisvgm 2.11.1, on Solaris 11.4, patchlevel 11.4.38.101.6 (the latest one). dvisvgm gives the following error:

$ /moodle/tools/texlive/2021-11-24/bin/x86_64-solaris/dvisvgm -E beispiel.ps -o beispiel.svg processing EPS file graphic size: 100.375pt x 18.0675pt (35.277778mm x 6.35mm) output written to beispiel.svg file converted in 0.526434 seconds Segmentation Fault (core dumped)

The output file looks OK, but after creating it, the program crashes. On a test VM the error does not occur. The dvisvgm binary is identical, it has the same version number and the same checksum:

$ cksum dvisvgm 1610221261 7172848 dvisvgm

The test VM however does not get any patches, so it has an old patchlevel: 11.4.0.15.0 Is it possible that this is the reason, i. e., dvisvgm does not work on newer Solaris versions?

mgieseki commented 2 years ago

I don't have a Solaris system available, so unfortunately I can't say anything about the TeX Live build of dvisvgm for Solaris at the moment. Maybe @mojca could give some feedback?

mgieseki commented 2 years ago

Since I can't help you with this issue, you might also want to ask for information on the TL mailing list.

mojca commented 2 years ago

I read this, but I have no clue what to check, in particular if it doesn't fail with older versions (I have access to Solaris 10, I would need to install a new VM in order to test 11.4, but I'm not too eager to do it). Are you able to build dvisvgm yourself and check if that one crashes as well?

joachim42 commented 2 years ago

Running Solaris 11.4 on a VM probably won't help anyway. I got a VM with an early version of 11.4 myself, and dvisvgm is working fine on it, so I suspect the error occurs only on very recent patchlevels (which AFAIK are not available for VMs). Now trying to compile dvisvgm on one of our "real" Solaris servers.

joachim42 commented 2 years ago

So far my attempts to compile dvisvgm on Solaris have failed because of kpathsea. There is no precompiled kpathsea library for Solaris (as opposite to Linux), i. e., libkpathsea.so.6 is not available. The TexLive distribution doesn't contain the library either, there are only a few executables which I assume have been statically linked with the kpathsea library, but the library itself is not present. So I'll have to build that one myself too, independent from Tex, but couldn't find any information how to do it. Does anybody know where I should look?

mgieseki commented 2 years ago

I guess the easiest way would be to check out the TeX Live sources from the SVN or Git repository and build the desired components from there. The build process is pretty straight forward although a bit time-consuming, and ensures that you get compatible libraries and executables.

joachim42 commented 2 years ago

After some initial trouble I managed to compile TeXLive from source (just compiled it all for simplicity). Upon first invocation of dvisvgm, there were a few error messages ...

$ ./dvisvgm -E ~/beispiel.ps -o ~/beispiel.svg processing EPS file WARNING: PostScript header file tex.pro not found WARNING: PostScript header file texps.pro not found WARNING: PostScript header file special.pro not found WARNING: PostScript header file color.pro not found PostScript error: undefined in TeXDict

... which could be fixed by setting the environment variable TEXPSHEADERS:

$ TEXPSHEADERS=~/texlive-20210324-source/inst/texmf-dist/dvips/base ./dvisvgm -E ~/beispiel.ps -o ~/beispiel.svg processing EPS file graphic size: 100.375pt x 18.0675pt (35.277778mm x 6.35mm) output written to ../../../../beispiel.svg file converted in 0.13156 seconds

(Environment variable was no longer necessary as soon as I put the new binary into the production directory where the original resides.)

The new, self-compiled binary works. Version number is the same as the original (2.11.1), but the binaries are different.

Original:

$ ls -l dvisvgm -rwxr-xr-x 1 root root 7172848 Feb 26 2021 dvisvgm

$ ldd dvisvgm librt.so.1 => /lib/64/librt.so.1 libm.so.2 => /lib/64/libm.so.2 libc.so.1 => /lib/64/libc.so.1

Self-compiled:

$ ls -l dvisvgm-test -rwxr-xr-x 1 noffke moodle 5858496 Dec 17 09:32 dvisvgm-test

$ ldd dvisvgm-test libstdc++.so.6 => /usr/lib/64/libstdc++.so.6 libm.so.2 => /lib/64/libm.so.2 librt.so.1 => /lib/64/librt.so.1 libgcc_s.so.1 => /usr/lib/64/libgcc_s.so.1 libc.so.1 => /lib/64/libc.so.1

Does this give any clue where the problem might be? As we have quite a few Solaris servers, it would be very convenient if we could continue using the precompiled TexLive archive (install-tl-unx.tar.gz).

mgieseki commented 2 years ago

I can't really tell what's the issue here but I suppose it's related to incompatible changes in the system libraries. Do the Solaris release notes or change logs contain any hints about that? Additionally, you could run dvisvgm via Valgrind and check if the output contains further helpful information about the origin of the segfault. Since the TL binaries are probably optimized and don't contain debug symbols, it might not be the case, though.

mojca commented 2 years ago

I can compile on the same system with debug symbols on if that helps in any way.

joachim42 commented 2 years ago

Yes please. Would be worth trying.

mgieseki commented 2 years ago

@joachim42 have you been able to get the problem sorted? Can we close the issue here?

joachim42 commented 2 years ago

I still don't have a working precompiled binary, but the one I compiled myself is OK, so I'll use this one if necessary. So yes, closing the issue now.