Bugs item #498, was opened at 2006-03-27 01: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: Vladimir Volovich (vvv) Date: 2006-03-27 11: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 04: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 02: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