[Dvipng] DVIPNG segfault on DVI output of simple TEX file?

[Shriramana Sharma]

Hello. The last post on this list was from last year but I hope people
are still around:

I'm running Kubuntu Raring, with versions as below:
texlive-base: 2012.20120611-5
dvipng: 1.14-1build1

I have this simple document foo.tex:

\documentclass[16pt]{article}
\usepackage{amsmath,amssymb}
\usepackage{breqn}
\pagestyle{empty}
\begin{document}
$ \infty $
\end{document}

I do latex foo.tex and I get the .dvi files with no problems. Then I do:

dvipng -T tight -D 150 -bg Transparent -fg Blue -O 0cm,0cm foo.png foo.dvi

I get this:

This is dvipng 1.14 Copyright 2002-2010 Jan-Ake Larsson
Segmentation fault (core dumped)

gdb says there are no debugging symbols so I couldn't try that.

Due to this dvipng problem I am not able to use SymPyPrt on
IPython2/3: https://groups.google.com/d/msg/sympy/WzwS3578TuU/sZAYDcFQ8cIJ

I did not have a problem with using SymPyPrt on Kubuntu Precise of
last year, and dvipng has practically not changed in Raring since
Precise: http://packages.ubuntu.com/search?keywords=dvipng&searchon=names&suite=all&section=all
except for a new build. The changelog
http://changelogs.ubuntu.com/changelogs/pool/main/d/dvipng/dvipng_1.14-1build1/changelog
says it's for some kpathsea transition but I'm not sure whether that
would be the cause of the problem.

I hope Jan or someone else can help me. Thank you!

[Jan-Åke Larsson]

There isn't much traffic these days, I dont have much time to put either.

The below works for me (linux mint) so either there is a build problem
or something to do with your setup.

In any case, it is a standard image, so if that doesn't work, then
nothing will. I would have many bug reports if everyone sees this.

Have you tried adding -d?

Perhaps it needs a newer kpathsea, but doesn't say so in the dependencies?

Best,
/JÅ

Post by Shriramana Sharma
Hello. The last post on this list was from last year but I hope people
texlive-base: 2012.20120611-5
dvipng: 1.14-1build1
\documentclass[16pt]{article}
\usepackage{amsmath,amssymb}
\usepackage{breqn}
\pagestyle{empty}
\begin{document}
$ \infty $
\end{document}
dvipng -T tight -D 150 -bg Transparent -fg Blue -O 0cm,0cm foo.png foo.dvi
This is dvipng 1.14 Copyright 2002-2010 Jan-Ake Larsson
Segmentation fault (core dumped)
gdb says there are no debugging symbols so I couldn't try that.
Due to this dvipng problem I am not able to use SymPyPrt on
IPython2/3: https://groups.google.com/d/msg/sympy/WzwS3578TuU/sZAYDcFQ8cIJ
I did not have a problem with using SymPyPrt on Kubuntu Precise of
last year, and dvipng has practically not changed in Raring since
Precise: http://packages.ubuntu.com/search?keywords=dvipng&searchon=names&suite=all&section=all
except for a new build. The changelog
http://changelogs.ubuntu.com/changelogs/pool/main/d/dvipng/dvipng_1.14-1build1/changelog
says it's for some kpathsea transition but I'm not sure whether that
would be the cause of the problem.
I hope Jan or someone else can help me. Thank you!

[Shriramana Sharma]

Hello Jan and thanks for your reply.

On Mon, Jun 17, 2013 at 10:54 AM, Jan-Åke Larsson

Post by Jan-Åke Larsson
Have you tried adding -d?

Yes I have but to no use. There are no additional messages being printed.

Post by Jan-Åke Larsson
Perhaps it needs a newer kpathsea, but doesn't say so in the dependencies?

Given all this, it would seem that since the only change from Precise
is due to the kpathsea, that should be the problem. I have reported:
https://bugs.launchpad.net/ubuntu/+source/dvipng/+bug/1191673

[Shriramana Sharma]

Post by Shriramana Sharma
Given all this, it would seem that since the only change from Precise
https://bugs.launchpad.net/ubuntu/+source/dvipng/+bug/1191673

OK so I built dvipng with -g3 and then ran gdb on it -- it seems that
dvipng is dereferencing a null pointer and that's the reason for the
segfault. So the problem may actually be within dvipng itself. I mean,
looking at the last few lines:

352 colornamep=LoadColornameFile(colordef[0]);
(gdb)
353 tmp=colornamep;
(gdb) print tmp
$11 = (struct colorname *) 0x0
(gdb) next
354 while((tmp->next!=NULL || colordef[unloaded]!=NULL)
(gdb) print tmp
$13 = (struct colorname *) 0x0
(gdb) next
Program received signal SIGSEGV, Segmentation fault.

It is evident that there is no check here to ensure that tmp is *not*
NULL before dereferencing it by -> on line 354.

[Shriramana Sharma]

Post by Shriramana Sharma
352 colornamep=LoadColornameFile(colordef[0]);
(gdb)
353 tmp=colornamep;
(gdb) print tmp
$11 = (struct colorname *) 0x0
(gdb) next
354 while((tmp->next!=NULL || colordef[unloaded]!=NULL)
(gdb) print tmp
$13 = (struct colorname *) 0x0
(gdb) next
Program received signal SIGSEGV, Segmentation fault.
It is evident that there is no check here to ensure that tmp is *not*
NULL before dereferencing it by -> on line 354.

So tmp evidently becomes NULL only because it is assigned to the
output of LoadColorFileName. I figured that function returned NULL
because it couldn't find the file asked for. So I did the next/step
routine again and asked gdb what colordef[0] was:

352 colornamep=LoadColornameFile(colordef[0]);
(gdb) print colordef[0]
$1 = 0x417de8 "xcolor.sty"
(gdb) print colordef
$2 = {0x417de8 "xcolor.sty", 0x417df3 "dvipsnam.def", 0x417e00
"svgnam.def", 0x417e0b "x11nam.def", 0x0}

Then I did searched on packages.ubuntu.com for packages providing
xcolor.sty: http://packages.ubuntu.com/search?searchon=contents&keywords=xcolor.sty&mode=exactfilename&suite=raring&arch=any

Sure enough, latex-xcolor
(http://packages.ubuntu.com/raring/latex-xcolor) wasn't installed on
my system and installing it fixed everything right up to the
functioning of SymPyPrt on IPy3.

So there are two bugs here:

dvipng's color.c has a bug whereby it does not test for the output of
LoadColorFileName to be NULL when it should output a meaningful error
message complaining that it could not find xcolor.sty.

Debian's dvipng packaging (inherited by Ubuntu) has the bug whereby it
does not have a dependency on latex-xcolor to provide the requisite
color data files that dvipng expects.

I hope this helps. I'll be filing a Debian bug and update the Ubuntu
bug accordingly. Please do fix this and issue a point release for
dvipng.

[Jan-Åke Larsson]

Thanks for the bug report. This comes from initiating the color list
from a file that exists in any latex dist, and then deciding that xcolor
should have priority.

Will be fixed in the next release. Perhaps I have time to do that on my
vacation.

/JÅ

Post by Shriramana Sharma

Post by Shriramana Sharma
352 colornamep=LoadColornameFile(colordef[0]);
(gdb)
353 tmp=colornamep;
(gdb) print tmp
$11 = (struct colorname *) 0x0
(gdb) next
354 while((tmp->next!=NULL || colordef[unloaded]!=NULL)
(gdb) print tmp
$13 = (struct colorname *) 0x0
(gdb) next
Program received signal SIGSEGV, Segmentation fault.
It is evident that there is no check here to ensure that tmp is *not*
NULL before dereferencing it by -> on line 354.

So tmp evidently becomes NULL only because it is assigned to the
output of LoadColorFileName. I figured that function returned NULL
because it couldn't find the file asked for. So I did the next/step
352 colornamep=LoadColornameFile(colordef[0]);
(gdb) print colordef[0]
$1 = 0x417de8 "xcolor.sty"
(gdb) print colordef
$2 = {0x417de8 "xcolor.sty", 0x417df3 "dvipsnam.def", 0x417e00
"svgnam.def", 0x417e0b "x11nam.def", 0x0}
Then I did searched on packages.ubuntu.com for packages providing
xcolor.sty: http://packages.ubuntu.com/search?searchon=contents&keywords=xcolor.sty&mode=exactfilename&suite=raring&arch=any
Sure enough, latex-xcolor
(http://packages.ubuntu.com/raring/latex-xcolor) wasn't installed on
my system and installing it fixed everything right up to the
functioning of SymPyPrt on IPy3.
dvipng's color.c has a bug whereby it does not test for the output of
LoadColorFileName to be NULL when it should output a meaningful error
message complaining that it could not find xcolor.sty.
Debian's dvipng packaging (inherited by Ubuntu) has the bug whereby it
does not have a dependency on latex-xcolor to provide the requisite
color data files that dvipng expects.
I hope this helps. I'll be filing a Debian bug and update the Ubuntu
bug accordingly. Please do fix this and issue a point release for
dvipng.

[Shriramana Sharma]

Post by Jan-Åke Larsson
from a file that exists in any latex dist, and then deciding that xcolor
should have priority.
Will be fixed in the next release. Perhaps I have time to do that on my
vacation.

So is xcolor.sty essential for dvipng or just recommended? I am filing
the Debian bug right now and would like to know if it should be a
dependency or just recommended?

[Shriramana Sharma]

Since it segfaults now, yes. Installing xcolor is a workaround. After
fixing that it would be merely recommended.

Thanks for your replies. IIUC xcolors.sty is only second preference
for color data. What is then the first preference color data file so I
can know which latex package contains it? Thanks.

[Jan-Åke Larsson]

Post by Shriramana Sharma
Thanks for your replies. IIUC xcolors.sty is only second preference
for color data. What is then the first preference color data file so I
can know which latex package contains it? Thanks.

%% This is file `dvipsnam.def',
%% generated with the docstrip utility.
%%
%% The original source files were:
%%
%% drivers.dtx (with options: `dvipsnames')
%%
%% drivers.dtx Copyright (C) 1994 David Carlisle Sebastian Rahtz
%% Copyright (C) 1995 1996 1997 1998 1999 David Carlisle
%%
%% This file is part of the Standard LaTeX `Graphics Bundle'.

This is in texlive-latex-base.

/JÅ

[Jan-Åke Larsson]

Post by Shriramana Sharma

Post by Jan-Åke Larsson
from a file that exists in any latex dist, and then deciding that xcolor
should have priority.
Will be fixed in the next release. Perhaps I have time to do that on my
vacation.

So is xcolor.sty essential for dvipng or just recommended? I am filing
the Debian bug right now and would like to know if it should be a
dependency or just recommended?

Since it segfaults now, yes. Installing xcolor is a workaround. After
fixing that it would be merely recommended.

/JÅ