[Latex2rtf-users] latex2rtf segmentation fault when equation is transformed into bitmap

[Ronan Arraes Jardim Chagas]

Hi!

I'm trying to submit latex2rtf package to openSUSE Leap 42.2, but I am having a
very strange behavior.

If I try to convert the following .tex file into an .rtf with the option to
transform the equations to bitmaps (-M12), then I get a segmentation fault just
before the conversion.

----------
\documentclass{article}
\begin{document}
\begin{equation}
    \int_{0}^{t} dx
\end{equation}
\end{document}
----------

However, if I remove two spaces before the integral sign, then everything is
fine:

----------
\documentclass{article}
\begin{document}
\begin{equation}
  \int_{0}^{t} dx
\end{equation}
\end{document}
----------

Notice that this problem does not happen in openSUSE Tumbleweed, which is
rolling release and the packages are much more updated. Thus, I think it is
related to some old package, but I cannot figure out what is causing the
problem.

Here is the backtrace of the segmentation fault:

----------
latex2rtf -M12 teste.tex 
teste.tex:2   Rendering '\begin{equation}     \i ... ^{t} dx \end{equation}'***
Error in `latex2rtf': free(): invalid pointer: 0x00000000011f40c0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7275f)[0x7f972622075f]
/lib64/libc.so.6(+0x77fce)[0x7f9726225fce]
latex2rtf[0x42809d]
latex2rtf[0x42ce14]
latex2rtf[0x41e534]
latex2rtf[0x41e7c1]
latex2rtf[0x404a01]
latex2rtf[0x405ade]
latex2rtf[0x4048ec]
latex2rtf[0x42189a]
latex2rtf[0x42074e]
latex2rtf[0x42046a]
latex2rtf[0x412ca3]
latex2rtf[0x412b53]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f97261cfb05]
latex2rtf[0x401979]
======= Memory map: ========
00400000-0044c000 r-xp 00000000 00:25
223826                             /usr/bin/latex2rtf
0064b000-0064c000 r--p 0004b000 00:25
223826                             /usr/bin/latex2rtf
0064c000-00656000 rw-p 0004c000 00:25
223826                             /usr/bin/latex2rtf
00656000-0067c000 rw-p 00000000 00:00 0 
011d7000-011f8000 rw-p 00000000 00:00 0                                  [heap]
7f9725f97000-7f9725fad000 r-xp 00000000 00:25
13002                      /lib64/libgcc_s.so.1
7f9725fad000-7f97261ac000 ---p 00016000 00:25
13002                      /lib64/libgcc_s.so.1
7f97261ac000-7f97261ad000 r--p 00015000 00:25
13002                      /lib64/libgcc_s.so.1
7f97261ad000-7f97261ae000 rw-p 00016000 00:25
13002                      /lib64/libgcc_s.so.1
7f97261ae000-7f972634c000 r-xp 00000000 00:25
13001                      /lib64/libc-2.19.so
7f972634c000-7f972654c000 ---p 0019e000 00:25
13001                      /lib64/libc-2.19.so
7f972654c000-7f9726550000 r--p 0019e000 00:25
13001                      /lib64/libc-2.19.so
7f9726550000-7f9726552000 rw-p 001a2000 00:25
13001                      /lib64/libc-2.19.so
7f9726552000-7f9726556000 rw-p 00000000 00:00 0 
7f9726556000-7f9726656000 r-xp 00000000 00:25
13112                      /lib64/libm-2.19.so
7f9726656000-7f9726855000 ---p 00100000 00:25
13112                      /lib64/libm-2.19.so
7f9726855000-7f9726856000 r--p 000ff000 00:25
13112                      /lib64/libm-2.19.so
7f9726856000-7f9726857000 rw-p 00100000 00:25
13112                      /lib64/libm-2.19.so
7f9726857000-7f9726878000 r-xp 00000000 00:25
13020                      /lib64/ld-2.19.so
7f9726a5b000-7f9726a5e000 rw-p 00000000 00:00 0 
7f9726a73000-7f9726a77000 rw-p 00000000 00:00 0 
7f9726a77000-7f9726a78000 r--p 00020000 00:25
13020                      /lib64/ld-2.19.so
7f9726a78000-7f9726a79000 rw-p 00021000 00:25
13020                      /lib64/ld-2.19.so
7f9726a79000-7f9726a7a000 rw-p 00000000 00:00 0 
7ffedb8a9000-7ffedb8de000 rw-p 00000000 00:00 0                          [stack]
7ffedb9d6000-7ffedb9d9000 r--p 00000000 00:00 0                          [vvar]
7ffedb9d9000-7ffedb9db000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00
0                  [vsyscall]
Abortado
----------

The full output of the command with -d6 flag can be found here:
http://pastebin.com/fH3KPKAq

Does anyone have any idea why this is happening?

Regards,
Ronan Arraes

[Wilfried Hennings]

Hello all,
I cannot reproduce the problem, the test file converts just nice on my
Windows 7 system with the current version of latex2rtf.
As the problem may not affect the majority of you, I write to the author
by personal e-mail. I will report if the problem is identified and / or
solved.
Wilfried

Post by Ronan Arraes Jardim Chagas
Hi!
I'm trying to submit latex2rtf package to openSUSE Leap 42.2, but I am having a
very strange behavior.
If I try to convert the following .tex file into an .rtf with the option to
transform the equations to bitmaps (-M12), then I get a segmentation fault just
before the conversion.
----------
\documentclass{article}
\begin{document}
\begin{equation}
\int_{0}^{t} dx
\end{equation}
\end{document}
----------
However, if I remove two spaces before the integral sign, then everything is
----------
\documentclass{article}
\begin{document}
\begin{equation}
\int_{0}^{t} dx
\end{equation}
\end{document}
----------
Notice that this problem does not happen in openSUSE Tumbleweed, which is
rolling release and the packages are much more updated. Thus, I think it is
related to some old package, but I cannot figure out what is causing the
problem.
----------
[snip]
----------
http://pastebin.com/fH3KPKAq
Does anyone have any idea why this is happening?
Regards,
Ronan Arraes
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Latex2rtf-users mailing list
https://lists.sourceforge.net/lists/listinfo/latex2rtf-users

[Ronan Arraes Jardim Chagas]

Hi Wilfried,

Thanks for the answer.

Post by Wilfried Hennings
I cannot reproduce the problem, the test file converts just nice on my
Windows 7 system with the recent versions (2.3.8, 2.3.9 and 2.3.10) of
latex2rtf.
Please check
- whether using the latest latex2rtf source code from sourceforge solves
the problem,

I'm using the latest version (2.3.10) and I can only reproduce the problem in
openSUSE Leap 42.2 Alpha 1. It works fine in openSUSE Tumbleweed. Hence, one
possible cause is an outdated package that I need to update for the release of
42.2.

Post by Wilfried Hennings
- check whether latex2rtf writes the file l2r_0001.tex to disk,

No, the `l2r_0001.tex` file *is not* being written to disk. It is falling before
this state. Does this add any new information for the bug?

Regards,
Ronan Arraes

[Ronan Arraes Jardim Chagas]

Hi Wilfried,

Thanks! I could track down the problem after your message.

If I recompile latex2rtf removing the following line (graphics.c:1917):

    safe_free(abbrev);

then everything works perfectly. Thus, the problem is that `abbrev` pointer is
consider invalid and we have a segmentation fault when free() is called.

I also noticed why if I remove two spaces no problem happens. When I do this,
then the string passed to abbreviate() function have less than 50 characters.
Hence, the string is just copied using strdup() and everything seems to be fine.
On the other hand, with the two additional spaces, then the string will have 51
characters. In this case, the code in graphics.c:1870 is executed and, for some
reason, it returns a pointer that cannot be freed (I'm still trying to figure
out what is causing this). Any ideas?

Best regards,
Ronan

Post by Ronan Arraes Jardim Chagas
Hi Wilfried,
Thanks for the answer.
I'm using the latest version (2.3.10) and I can only reproduce the problem in
openSUSE Leap 42.2 Alpha 1. It works fine in openSUSE Tumbleweed. Hence, one
possible cause is an outdated package that I need to update for the release of
42.2.

Post by Wilfried Hennings
- check whether latex2rtf writes the file l2r_0001.tex to disk,

No, the `l2r_0001.tex` file *is not* being written to disk. It is falling before
this state. Does this add any new information for the bug?

Yes, this information is helpful.
This file should be written in source file graphics.c lines 1807 to 1843
in function *SaveEquationAsFile
called from function WriteLatexAsBitmapOrEPS
The last line in the debug output is
"Rendering '\begin{equation}     \i ... ^{t} dx \end{equation}'"
This is output by function WriteLatexAsBitmapOrEPS in source file
graphics.c in line 1916.
The problem is likely to occur shortly after this.
As the diagnostic "SaveEquationAsFile = ..." is NOT output,
which is output in graphics.c line 1805,
I guess the problem is in line 1798 calling
tmp_dir = getTmpPath();
This function is defined in source file main.c ,
and contains e.g. line 914
        u = getenv("TMPDIR");
Could it be that the getenv system function does not work as intended?
Regards
Wilfried

[Ronan Arraes Jardim Chagas]

Wilfried,

We have a memory leak in abbreviate function!
I could fix the problem by changing:

    t = (char *) malloc(len * sizeof(char));

to

    t = (char *) malloc((len+1) * sizeof(char));

Notice that in the last `for` (graphics.c:1895), the last parameter written is:

    t[half + 6 + half]

Since:

    half = (len - 6)/2;

and len = 50, then half = 22. Therefore, we are writing to t[50], or the 51st
term. However, the `malloc` allocates only 50 terms, which leaded to the
problem.

I will submit a patch to the openSUSE package. Can you explain me how can I also
send the patch to the official latex2rtf tree?

Regards,
Ronan Arraes