FS#62685 - [texlive-bin] xdvipdfmx crashes with SIGSEGV for some Chinese documents

Attached to Project: Arch Linux
Opened by Chih-Hsuan Yen (yan12125) - Monday, 20 May 2019, 18:39 GMT
Last edited by Rémy Oudompheng (remyoudompheng) - Sunday, 07 June 2020, 14:31 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Rémy Oudompheng (remyoudompheng)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
The following document cannot be compiled with command `xelatex chinese.tex`:

\documentclass{article}
\usepackage{fontspec}
\usepackage{xeCJK}
\setCJKmainfont{AR PL UMing TW}
\begin{document}
中文內容
\end{document}

The error message is:

Error 139 (driver return code) generating output;

If I use "Noto Serif CJK TC" in \setCJKmainfont, the document compiles fine.

I managed to get a backtrace by splitting the original command into two:

$ xelatex -no-pdf chinese.tex
$ xdvipdfmx -o chinese.pdf < chinese.xdv

The gdb backtrace of the second command is:

#0 0x00005555555d9bf0 in add_ligature1_inverse_map (cmap=cmap@entry=0x555555b70960, used_chars=used_chars@entry=0x555555b5e010 "", map_base=map_base@entry=0x555555ba7750, map_sub=map_sub@entry=0x555555bc1f30, num_glyphs=num_glyphs@entry=27123, GIDToCIDMap=GIDToCIDMap@entry=0x555555bdc710, gid_1=40, idx=1, data=0x555555b5dbf0) at ../../../texk/dvipdfm-x/tt_gsub.c:1891
#1 0x00005555555db2c6 in add_ligature1_inverse_map (data=0x555555b5dbf0, idx=1, gid_1=<optimized out>, GIDToCIDMap=0x555555bdc710, num_glyphs=27123, map_sub=0x555555bc1f30, map_base=0x555555ba7750, used_chars=0x555555b5e010 "", cmap=0x555555b70960) at ../../../texk/dvipdfm-x/tt_gsub.c:1962
#2 add_ToUnicode_ligature (GIDToCIDMap=0x555555bdc710, num_glyphs=27123, map_sub=0x555555bc1f30, map_base=0x555555ba7750, subtab=<optimized out>, used_chars=0x555555b5e010 "", cmap=0x555555b70960) at ../../../texk/dvipdfm-x/tt_gsub.c:1962
#3 otl_gsub_add_ToUnicode (cmap=cmap@entry=0x555555b70960, used_chars=used_chars@entry=0x555555b5e010 "", map_base=map_base@entry=0x555555ba7750, map_sub=map_sub@entry=0x555555bc1f30, num_glyphs=num_glyphs@entry=27123, GIDToCIDMap=GIDToCIDMap@entry=0x555555bdc710, sfont=0x555555b597d0) at ../../../texk/dvipdfm-x/tt_gsub.c:2017
#4 0x00005555555d42b6 in create_ToUnicode_cmap (ttcmap=ttcmap@entry=0x555555b71960, cmap_name=cmap_name@entry=0x555555b717f0 "FPXCHX+UMingTW-UTF16", cmap_add=cmap_add@entry=0x0, used_chars=used_chars@entry=0x555555b6ac30 "", sfont=sfont@entry=0x555555b597d0) at ../../../texk/dvipdfm-x/tt_cmap.c:992
#5 0x00005555555d50e0 in otf_create_ToUnicode_stream (font_name=0x555555b646e0 "/usr/share/fonts/TTF/uming.ttc", ttc_index=ttc_index@entry=2, basefont=basefont@entry=0x555555b67120 "FPXCHX+UMingTW", used_chars=used_chars@entry=0x555555b6ac30 "") at ../../../texk/dvipdfm-x/tt_cmap.c:1174
#6 0x00005555555dd98c in Type0Font_attach_ToUnicode_stream (font=0x555555b68810) at ../../../texk/dvipdfm-x/type0.c:328
#7 Type0Font_dofont (font=0x555555b68810) at ../../../texk/dvipdfm-x/type0.c:285
#8 Type0Font_cache_close () at ../../../texk/dvipdfm-x/type0.c:562
#9 0x00005555555a8529 in pdf_close_fonts () at ../../../texk/dvipdfm-x/pdffont.c:541
#10 0x00005555555a02fb in pdf_close_document () at ../../../texk/dvipdfm-x/pdfdoc.c:2584
#11 0x0000555555568e96 in main (argc=<optimized out>, argv=<optimized out>) at ../../../texk/dvipdfm-x/dvipdfmx.c:1236

By the way, running the same command under valgrind gives a correct PDF file:

$ valgrind xdvipdfmx -o chinese.pdf < chinese.xdv
==28334== Memcheck, a memory error detector
==28334== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==28334== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==28334== Command: xdvipdfmx -o chinese.pdf
==28334==
stdin -> stdout
[1]==28334== Conditional jump or move depends on uninitialised value(s)
==28334== at 0x18DB9B: add_ligature1_inverse_map.part.7 (tt_gsub.c:1890)
==28334== by 0x18F2C5: add_ligature1_inverse_map (tt_gsub.c:1885)
==28334== by 0x18F2C5: add_ToUnicode_ligature (tt_gsub.c:1962)
==28334== by 0x18F2C5: otl_gsub_add_ToUnicode (tt_gsub.c:2017)
==28334== by 0x1882B5: create_ToUnicode_cmap (tt_cmap.c:992)
==28334== by 0x1890DF: otf_create_ToUnicode_stream (tt_cmap.c:1174)
==28334== by 0x19198B: Type0Font_attach_ToUnicode_stream (type0.c:232)
==28334== by 0x19198B: Type0Font_dofont (type0.c:285)
==28334== by 0x19198B: Type0Font_cache_close (type0.c:562)
==28334== by 0x15C528: pdf_close_fonts (pdffont.c:541)
==28334== by 0x1542FA: pdf_close_document (pdfdoc.c:2584)
==28334== by 0x11CE95: main (dvipdfmx.c:1236)
==28334==
==28334== Conditional jump or move depends on uninitialised value(s)
==28334== at 0x18DFE5: otl_gsub_release_ligature (tt_gsub.c:751)
==28334== by 0x18DFE5: otl_gsub_release.part.8 (tt_gsub.c:1443)
==28334== by 0x18F005: otl_gsub_release (tt_gsub.c:1420)
==28334== by 0x18F005: otl_gsub_add_ToUnicode (tt_gsub.c:2024)
==28334== by 0x1882B5: create_ToUnicode_cmap (tt_cmap.c:992)
==28334== by 0x1890DF: otf_create_ToUnicode_stream (tt_cmap.c:1174)
==28334== by 0x19198B: Type0Font_attach_ToUnicode_stream (type0.c:232)
==28334== by 0x19198B: Type0Font_dofont (type0.c:285)
==28334== by 0x19198B: Type0Font_cache_close (type0.c:562)
==28334== by 0x15C528: pdf_close_fonts (pdffont.c:541)
==28334== by 0x1542FA: pdf_close_document (pdfdoc.c:2584)
==28334== by 0x11CE95: main (dvipdfmx.c:1236)
==28334==
==28334== Conditional jump or move depends on uninitialised value(s)
==28334== at 0x4839961: free (vg_replace_malloc.c:530)
==28334== by 0x18E041: otl_gsub_release_ligature (tt_gsub.c:757)
==28334== by 0x18E041: otl_gsub_release.part.8 (tt_gsub.c:1443)
==28334== by 0x18F005: otl_gsub_release (tt_gsub.c:1420)
==28334== by 0x18F005: otl_gsub_add_ToUnicode (tt_gsub.c:2024)
==28334== by 0x1882B5: create_ToUnicode_cmap (tt_cmap.c:992)
==28334== by 0x1890DF: otf_create_ToUnicode_stream (tt_cmap.c:1174)
==28334== by 0x19198B: Type0Font_attach_ToUnicode_stream (type0.c:232)
==28334== by 0x19198B: Type0Font_dofont (type0.c:285)
==28334== by 0x19198B: Type0Font_cache_close (type0.c:562)
==28334== by 0x15C528: pdf_close_fonts (pdffont.c:541)
==28334== by 0x1542FA: pdf_close_document (pdfdoc.c:2584)
==28334== by 0x11CE95: main (dvipdfmx.c:1236)
==28334==

11877 bytes written
==28334==
==28334== HEAP SUMMARY:
==28334== in use at exit: 2,200,137 bytes in 82,764 blocks
==28334== total heap usage: 285,807 allocs, 203,043 frees, 16,483,280 bytes allocated
==28334==
==28334== LEAK SUMMARY:
==28334== definitely lost: 19,572 bytes in 733 blocks
==28334== indirectly lost: 3,996 bytes in 260 blocks
==28334== possibly lost: 0 bytes in 0 blocks
==28334== still reachable: 2,176,569 bytes in 81,771 blocks
==28334== suppressed: 0 bytes in 0 blocks
==28334== Rerun with --leak-check=full to see details of leaked memory
==28334==
==28334== For counts of detected and suppressed errors, rerun with: -v
==28334== Use --track-origins=yes to see where uninitialised values come from
==28334== ERROR SUMMARY: 168 errors from 3 contexts (suppressed: 0 from 0)

Additional info:
texlive-bin 2019.51075-1 (rbuilt with `options=("debug" "!strip")`)
texlive-core 2019.50917-1
texlive-langchinese 2019.50850-1
texlive-latexextra 2019.50920-1
ttf-arphic-uming 0.2.20080216.1-7
noto-fonts-cjk 20190409-1

Steps to reproduce: see above
This task depends upon

Closed by  Rémy Oudompheng (remyoudompheng)
Sunday, 07 June 2020, 14:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  texlive-bin 2020.54586-3
Comment by Chih-Hsuan Yen (yan12125) - Tuesday, 21 May 2019, 03:18 GMT
Follow-up: my upstream bug report mail is approved https://tug.org/pipermail/dvipdfmx/2019-May/000004.html
Comment by Chih-Hsuan Yen (yan12125) - Thursday, 23 May 2019, 15:35 GMT
Upstream dev pushed a commit https://github.com/TeX-Live/texlive-source/commit/11575460d25e29c6b9189cfad2725e7942869fc6. If I add this commit on top of 2019.2, all my Chinese documents build fine. Could you consider adding the commit to the Arch Linux package?
Comment by Rémy Oudompheng (remyoudompheng) - Sunday, 07 June 2020, 14:29 GMT
The problem is no longer there with TL 2020 packages.

Loading...