June 2008 - ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 07 Jun '08

07 Jun '08

Bugs item #1242, was opened at 2008-06-06 14:53 >Status: Open Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: Invalid Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2008-06-07 09:39 Message: I can see this is can easily be a problem everywhere, especially in networked environments, so will reopen the report, but file locking is probably not the best way to fix the symptoms. Locking files (and detecting locks) on a local harddisk is already quite hard to implement in a portable manner, never mind attempting todo the same over a network share. So if you really want file locking, you probably should talk to the miktex maintainer, as that is not likely to make it into pdftex (or luatex)'s core distribution. However, it would be pretty easy to make pdftex create a PDF file with a temporary name and rename it only at the end of a succesful run. As a side bonus, that would also prevent the existance of partial == broken pdfs. I believe that is something to consider for 1.50 or luatex. ---------------------------------------------------------------------- Comment By: William Blum (wblum) Date: 2008-06-06 23:20 Message: > We don't support MikTeX-pdfTeX; please discuss this with the > MikTeX maintainer. This bug does not affect only MikTex! I have just tried with teTeX on cygwin and the same problem occurs. I suspect that all TeX distributions suffer from the same bug since there is no reason for them to change the way the files are opened by pdftex. Since all distributions derive from the pdftex code maintained here, I though it would make more sense to patch the bug at the source... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-06 15:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 06 Jun '08

06 Jun '08

Bugs item #1242, was opened at 2008-06-06 13:53 Status: Closed Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: Invalid Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- Comment By: William Blum (wblum) Date: 2008-06-06 22:20 Message: > We don't support MikTeX-pdfTeX; please discuss this with the > MikTeX maintainer. This bug does not affect only MikTex! I have just tried with teTeX on cygwin and the same problem occurs. I suspect that all TeX distributions suffer from the same bug since there is no reason for them to change the way the files are opened by pdftex. Since all distributions derive from the pdftex code maintained here, I though it would make more sense to patch the bug at the source... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-06 14:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 06 Jun '08

06 Jun '08

Bugs item #1242, was opened at 2008-06-06 14:53 >Status: Closed Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access >Resolution: Invalid Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-06-06 15:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 06 Jun '08

06 Jun '08

Bugs item #1242, was opened at 2008-06-06 13:53 Status: Open Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: None Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

Announcement: changes and plan for pdftex
by The Thanh Han 05 Jun '08

05 Jun '08

Announcement: changes and plan for pdftex Dear all, in the context of the forthcoming luatex (which is supposed to be pdftex successor), the pdftex team has agreed on the following decisions: - we plan to release 1.40.8 soon, which will be included in texlive2008. The next version will be 1.50.0 and after that version, pdftex development will be essentially stopped. From 1.50.0 onwards, in principle only bug fixes are accepted. - from now on, pdftex will be maintained by me (Han The Thanh). I and all other members of the pdftex team thank Martin Schr\"oder for his great effort on pdftex maintainance over the years. Thanks to him we've seen a steady stream of pdftex releases. - more structural development takes place in the luatex project, which is a continuation of pdftex. However, we will still do our best to keep pdftex stable and compliant to pdf standards. In this respect, after 1.50.0 we might have to accept some extensions (most likely backported from luatex) that are required to keep pdftex compliant with new pdf standards, but only in case it is unavoidable. on the behalf of the pdftex team, Han The Thanh

1 0

! TeX capacity exceeded, sorry [parameter stack size=6000].
by Vit Zyka 02 Jun '08

02 Jun '08

Hi pdftex team, I have encountered the problem with the stack_size parameter. Enlarging a complex context document results in the error ! TeX capacity exceeded, sorry [parameter stack size=6000]. Since a compilation of individual document parts is OK I do not believe in the recurse problem. Interesting is that texmf.cnf sets (TL 07): stack_size = 5000 stack_size.context = 10000 so I was curious why pdftex (tested on 1.40.5 and the current 1.40.8) is writting about 6000. It seems to me it simply cuts down the number greater then 6000. - Is the 6000 a real limit? - If so then context setting to 10000 is useless. - If not can it be increased a bit? Let us say to 10000? Thanks Vit Zyka

3 2

Re: [NTG-pdftex] Bug#458059:
by Frank Küster 01 Jun '08

01 Jun '08

Dear TeX(-k) people, dear pdfTeX team, late last year Norbert Preining already asked on the TeXk list about a problem encountered in Debian, namely a TeX capacity exceeded error on grouping levels. Nobody could help back then, but now someone started to analyse this further (many thanks, Stijn!). So could you please (again) have a look? It seems the value is hardcoded in the sources, "Stijn van Drongelen" <tinctorius(a)gmail.com> wrote: > The issue seems to have its roots in build/source/texk/web2c/tex.web, > line 5925-5930: > > if cur_level=max_quarterword then overflow("grouping levels", > @:TeX capacity exceeded grouping levels}{\quad grouping levels@> > max_quarterword-min_quarterword); > {quit if |(cur_level+1)| is too big to be stored in |eqtb|} > cur_boundary:=save_ptr; incr(cur_level); incr(save_ptr); cur_group:=c; > end; > > So if 'cur_level' exceeds the maximum quarterword size, TeX dies. > These constants are defined in 2411-2414: > > @d min_quarterword=0 {smallest allowable value in a |quarterword|} > @d max_quarterword=255 {largest allowable value in a |quarterword|} > @d min_halfword==0 {smallest allowable value in a |halfword|} > @d max_halfword==65535 {largest allowable value in a |halfword|} > > And on line 2409, it says: "The values defined here are recommended > for most 32-bit computers." > > I use amd64. I can deal with max_quarterword=65535 etc. > > Why aren't these quarterword/halfword bounds configurable? There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error ! TeX capacity exceeded, sorry [grouping levels=255]. although my texmf.cnf has nest_size=500. Should/can we change max_quarterword, or are there side effects? Or should the grouping levels instead use halfword? Or would you like to do it in a completely different way? This is a real life problem which affects building the PostgreSQL documentatin. Many thanks in advance, Frank -- Frank Küster Debian Developer (teTeX/TeXLive)

6 11