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
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
|
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
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
Comment by
Chih-Hsuan Yen (yan12125) -
Thursday, 23 May 2019, 15:35 GMT
Comment by
Rémy Oudompheng (remyoudompheng) -
Sunday, 07 June 2020, 14:29 GMT
Follow-up: my upstream bug report mail is approved
https://tug.org/pipermail/dvipdfmx/2019-May/000004.html
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?
The problem is no longer there with TL 2020 packages.