Bugs item #498, was opened at 2006-03-26 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ----------------------------------------------------------------------

Comment By: Martin Schröder (oneiros) Date: 2006-03-27 14:51

Message: Logged In: YES user_id=421 Hans, please try it on Windows -- if it doesn't fail there, I'd be surprised. IIRC Fabrice' fix was for the \immediate version which also ran out of filedescriptors some years ago. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-03-27 09:52 Message: Logged In: YES user_id=927 (this problem does not occur on windows; i remember that fabrice looked into it long ago) there is a relationship between open files and using \immediate and/or the page key and/or re-use; using immediate solves the open file problems but may lead to bigger files; i asume that opening a file twice is taken care of since there was a request from choff (tug conference china) with respect to splitting the 'get dimensions' code (also needed for dvi mode) from the inclusion code it may make sense to look into that direction [for instance, provide a primitive to determine the dimensions and then always delay inclusion of the objects] there is also the matter of efficiently embedding fonts in included files (sharing with parent document) so that's another pitfall keeping files open has to do with sharing objects so patching this code in order to overcome the open file limits may turn out to be tricky ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv) Date: 2006-03-27 09:39 Message: Logged In: YES user_id=2086 please clarify why non-\immediate \pdfximage is still allowed to leave the included files opened. (i.e. why the current behavior is considered normal, when the files are left opened and the ulimit eventually overflows). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 02:58 Message: Logged In: YES user_id=421 The "problem" here is that \pdfximage normally is not immediate. If you make it immediate by e.g. inserting \let\mypdfximage\pdfximage \def\pdfximage{\immediate\mypdfximage} everything works fine. So maybe pdfpages should work use an \immediate. We still need to fix the problem with the remaining broken file, but that is another bug. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 00:43 Message: Logged In: YES user_id=421 I at least found why the resulting file is not deleted (i.e. where pdfTeX actually crashes): The callstack is thus: - pdftex.web:scan_image - writeimg.c:readimage - writeimg.c:checktypebyheader - kpathsea/xfopen.c:xfopen, which calls FATAL_PERROR So we should register our error handler through atexit (3) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106