User reports a double-free viewing a PDF with gv. The following command line also shows the problem: $ gs -sDEVICE=x11 -dTextAlphaBits=2 -dGraphicsAlphaBits=2 -dAlignToPixels=0 -dMaxBitmap=10000000 -dNOPLATFONTS -dNOPAUSE -dQUIET -dSAFER -dFIXEDMEDIA - < X0510_01.pdf Error: /invalidfileaccess in findresource [...stack dump...] Current allocation mode is global GPL Ghostscript 8.62: Unrecoverable error, exit code 1 *** glibc detected *** gs: double free or corruption (!prev): 0x08924658 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7aaea20] /lib/libc.so.6(cfree+0x89)[0xb7ab0709] /lib/libc.so.6(fclose+0x152)[0xb7a9eef2] gs[0x81157c3] gs(file_close_disable+0x13)[0x80f6173] gs(file_close_file+0x1a)[0x8115dca] gs(sclose+0x1b)[0x80f677b] gs(gs_gc_reclaim+0xbd3)[0x8111703] gs[0x8186d6b] gs[0x80ef350] gs(interp_reclaim+0x43)[0x80eb133] gs(gs_main_finit+0x100)[0x80e2b40] gs(main+0xee)[0x80884de] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7a5efdc] gs[0x8088361]
Created attachment 4229 [details] X0510_01.pdf
I've reproduced with trunk and the following minimal command line: $ debugobj/gs -dSAFER - < X0510_01.pdf The file uses Japanese fonts, and so the following must be added to lib/cidfmap: /Kochi-Gothic << /FileType /TrueType /Path (/usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf) /CSI [(Japan1) 6] >> ; /Kochi-Gothic-Regular /Kochi-Gothic ; /Kochi-Gothic-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf) /CSI [(Japan2) 0] >> ; /Kochi-Gothic-Regular-JaH /Kochi-Gothic-JaH ; /Kochi-Mincho << /FileType /TrueType /Path (/usr/share/fonts/truetype/kochi/kochi-mincho-subst.ttf) /CSI [(Japan1) 6] >> ; /Kochi-Mincho-Regular /Kochi-Mincho ; /Kochi-Mincho-JaH << /FileType /TrueType /Path (/usr/share/fonts/truetype/kochi/kochi-mincho-subst.ttf) /CSI [(Japan2) 0] >> ; /Kochi-Mincho-Regular-JaH /Kochi-Mincho-JaH ; /Ryumin-Light /Kochi-Mincho ; /GothicBBB-Medium /Kochi-Gothic ; /Adobe-Japan1 /Kochi-Gothic ; /Adobe-Japan2 /Kochi-Gothic-JaH ; These paths are specific to Ubuntu Linux. The user had different ones from the gentoo build. Both -dSAFER and feeding the file from stdin are necessary to reproduce the double free. The /invalidfileaccess is because the fonts referenced from cidfmap are not on the permitted read list. If they're added (for example with -I/usr/share/fonts/truetype/kochi in the example above) the double free is not reported. In this case the document still doesn't render past the first page, complaining: Loading a TT font from /usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf to emulate a CID font Kochi-Gothic ... Done. Error: /invalidfont in --.buildcidfont-- So there may be other issues with this file, or with the cidfmap used. The file appears to have some kind of javascript DRM, and displays as blank in evince and Apple Preview. Adobe Reader asks if the document can access itself through a url and when blocked also shows the document as blank. However the content is visible briefly when scrolling.
Double free can cause stability problems. We have many customers using Asian CID fonts, but I don't know if they are having 'PermitFileReading' problems (most don't bother with -dSAFER).
Use a proper destructor to free a file stream when access to the file is not permitted in the safe mode, not just close the file and drop the rest of the file structure. The following patch is committed as a rev. 9307. http://ghostscript.com/pipermail/gs-cvs/2008-December/008885.html Our standard regression testing doesn't cover the safe mode. Testing under Valgrind shows that double fclose() (and double free()) no longer occurs.