Обсуждение: PDF builds broken again
It seems at least the 9.0 PDFs are broken (trying to build for the release):
Lots of errors/warnings (and AFAIK no way to see which is which in the
output), but It hink this is the telltale as usual:
Overfull \hbox (7.12454pt too wide) in paragraph at lines 88092--88092[]\T1/pcr/m/n/9 CREATE FUNCTION getf1(myrowtype)
RETURNSint AS 'SELECT $1.f1'LANGUAGE SQL;[][]
....
and many more like it until
....
Overfull \hbox (1.59999pt too wide) in alignment at lines 241488--241741[] [] [][]
[256.0.1
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.
\AtBegShi@Output ...ipout \box \AtBeginShipoutBox \fi \fi
l.241875 ...char95{}stat\char95{}file('filename');
Here is how much of TeX's memory you used:22467 strings out of 482156171125 string characters out of 3785924308594
wordsof memory out of 308500027304 multiletter control sequences out of 15000+50000080861 words of font info for 131
fonts,out of 3000000 for 900014 hyphenation exceptions out of 819130i,12n,43p,307b,1338s stack positions out of
1500i,500n,1500p,200000b,50000s
! ==> Fatal error occurred, no output PDF file produced!
Do we actually have any buildfarm boxes building the PDFs? And if so,
any idea why they didn't catch it?
Do we have a reasonable way to figure out which commit actually broke
it, other than manually testing backing out each of the 11 commits
since 9.0.17?
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander <magnus@hagander.net> wrote:
> It seems at least the 9.0 PDFs are broken (trying to build for the release):
>
> Lots of errors/warnings (and AFAIK no way to see which is which in the
> output), but It hink this is the telltale as usual:
>
> Overfull \hbox (7.12454pt too wide) in paragraph at lines 88092--88092
> []\T1/pcr/m/n/9 CREATE FUNCTION getf1(myrowtype) RETURNS int AS 'SELECT $1.f1'
> LANGUAGE SQL;[]
> []
> ....
> and many more like it until
> ....
> Overfull \hbox (1.59999pt too wide) in alignment at lines 241488--241741
> [] [] []
> []
>
> [256.0.1
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
> fstartlink.
> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
> \fi \fi
> l.241875 ...char95{}stat\char95{}file('filename');
>
>
>
> Here is how much of TeX's memory you used:
> 22467 strings out of 482156
> 171125 string characters out of 3785924
> 308594 words of memory out of 3085000
> 27304 multiletter control sequences out of 15000+500000
> 80861 words of font info for 131 fonts, out of 3000000 for 9000
> 14 hyphenation exceptions out of 8191
> 30i,12n,43p,307b,1338s stack positions out of 1500i,500n,1500p,200000b,50000s
> ! ==> Fatal error occurred, no output PDF file produced!
>
>
>
>
> Do we actually have any buildfarm boxes building the PDFs? And if so,
> any idea why they didn't catch it?
>
> Do we have a reasonable way to figure out which commit actually broke
> it, other than manually testing backing out each of the 11 commits
> since 9.0.17?
Additional point of info - the -US pdf's do build on this version,
just not the -A4.
And with even more of those entries about overfull hbox, so clearly
that was not the actual breakage.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Wed, Jul 23, 2014 at 1:31 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> It seems at least the 9.0 PDFs are broken (trying to build for the release):
>>
>> Lots of errors/warnings (and AFAIK no way to see which is which in the
>> output), but It hink this is the telltale as usual:
>>
>> Overfull \hbox (7.12454pt too wide) in paragraph at lines 88092--88092
>> []\T1/pcr/m/n/9 CREATE FUNCTION getf1(myrowtype) RETURNS int AS 'SELECT $1.f1'
>> LANGUAGE SQL;[]
>> []
>> ....
>> and many more like it until
>> ....
>> Overfull \hbox (1.59999pt too wide) in alignment at lines 241488--241741
>> [] [] []
>> []
>>
>> [256.0.1
>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
>> fstartlink.
>> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>> \fi \fi
>> l.241875 ...char95{}stat\char95{}file('filename');
>>
>>
>>
>> Here is how much of TeX's memory you used:
>> 22467 strings out of 482156
>> 171125 string characters out of 3785924
>> 308594 words of memory out of 3085000
>> 27304 multiletter control sequences out of 15000+500000
>> 80861 words of font info for 131 fonts, out of 3000000 for 9000
>> 14 hyphenation exceptions out of 8191
>> 30i,12n,43p,307b,1338s stack positions out of 1500i,500n,1500p,200000b,50000s
>> ! ==> Fatal error occurred, no output PDF file produced!
>>
>>
>>
>>
>> Do we actually have any buildfarm boxes building the PDFs? And if so,
>> any idea why they didn't catch it?
>>
>> Do we have a reasonable way to figure out which commit actually broke
>> it, other than manually testing backing out each of the 11 commits
>> since 9.0.17?
>
> Additional point of info - the -US pdf's do build on this version,
> just not the -A4.
>
> And with even more of those entries about overfull hbox, so clearly
> that was not the actual breakage.
And with some dissecting, the offending patch is
6b2a1445ec8a631060c4cbff3f172bf31d3379b9.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Wed, Jul 23, 2014 at 3:15 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Wed, Jul 23, 2014 at 1:31 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>> It seems at least the 9.0 PDFs are broken (trying to build for the release):
>>>
>>> Lots of errors/warnings (and AFAIK no way to see which is which in the
>>> output), but It hink this is the telltale as usual:
>>>
>>> Overfull \hbox (7.12454pt too wide) in paragraph at lines 88092--88092
>>> []\T1/pcr/m/n/9 CREATE FUNCTION getf1(myrowtype) RETURNS int AS 'SELECT $1.f1'
>>> LANGUAGE SQL;[]
>>> []
>>> ....
>>> and many more like it until
>>> ....
>>> Overfull \hbox (1.59999pt too wide) in alignment at lines 241488--241741
>>> [] [] []
>>> []
>>>
>>> [256.0.1
>>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
>>> fstartlink.
>>> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>>> \fi \fi
>>> l.241875 ...char95{}stat\char95{}file('filename');
>>>
>>>
>>>
>>> Here is how much of TeX's memory you used:
>>> 22467 strings out of 482156
>>> 171125 string characters out of 3785924
>>> 308594 words of memory out of 3085000
>>> 27304 multiletter control sequences out of 15000+500000
>>> 80861 words of font info for 131 fonts, out of 3000000 for 9000
>>> 14 hyphenation exceptions out of 8191
>>> 30i,12n,43p,307b,1338s stack positions out of 1500i,500n,1500p,200000b,50000s
>>> ! ==> Fatal error occurred, no output PDF file produced!
>>>
>>>
>>>
>>>
>>> Do we actually have any buildfarm boxes building the PDFs? And if so,
>>> any idea why they didn't catch it?
>>>
>>> Do we have a reasonable way to figure out which commit actually broke
>>> it, other than manually testing backing out each of the 11 commits
>>> since 9.0.17?
>>
>> Additional point of info - the -US pdf's do build on this version,
>> just not the -A4.
>>
>> And with even more of those entries about overfull hbox, so clearly
>> that was not the actual breakage.
>
> And with some dissecting, the offending patch is
> 6b2a1445ec8a631060c4cbff3f172bf31d3379b9.
I ended up splitting the paragraph in two in order to get the PDFs to
build. I've applied a patch for this to 9.0 only so we can keep
building PDFs.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
> Additional point of info - the -US pdf's do build on this version,
> just not the -A4.
> And with even more of those entries about overfull hbox, so clearly
> that was not the actual breakage.
Yeah. What this actually is is the symptom of <link> text crossing a page
boundary. The patch you made did not fix the problem (because there's no
hyperlink anywhere in that para); you just moved the problematic line
pair, which must be somewhere below here, up or down so it didn't fall
across a page break.
A more robust fix would be to identify the para where the problem actually
is and re-word it so that the link doesn't cross a *line* boundary (in
either US or A4). That makes it safe as long as that particular para
doesn't get reworded in future; whereas with what you did, addition or
subtraction of a line anywhere in a pretty broad range could resurrect
the issue.
Of course, it would be a lot better if the toolchain didn't have this
limitation (or at least managed to report it more usefully). I'm not
holding my breath for that to happen though.
regards, tom lane
On Wed, Jul 23, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Wed, Jul 23, 2014 at 12:31 PM, Magnus Hagander <magnus@hagander.net> wrote: >>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd > >> Additional point of info - the -US pdf's do build on this version, >> just not the -A4. > >> And with even more of those entries about overfull hbox, so clearly >> that was not the actual breakage. > > Yeah. What this actually is is the symptom of <link> text crossing a page > boundary. The patch you made did not fix the problem (because there's no > hyperlink anywhere in that para); you just moved the problematic line > pair, which must be somewhere below here, up or down so it didn't fall > across a page break. Right - it fixed the symptoms only. (And now that you mention it I do remember the thing about <link>). > A more robust fix would be to identify the para where the problem actually > is and re-word it so that the link doesn't cross a *line* boundary (in > either US or A4). That makes it safe as long as that particular para > doesn't get reworded in future; whereas with what you did, addition or > subtraction of a line anywhere in a pretty broad range could resurrect > the issue. Hmm. Good point. OTOH it only showed up in the backbranch (and only in one of them), so I figured we might get away with it. Have you figured out any way to actually track down which para has the problem itself, or is it all manual work? > Of course, it would be a lot better if the toolchain didn't have this > limitation (or at least managed to report it more usefully). I'm not > holding my breath for that to happen though. Yeah, they would probably have done it years ago if they were going to at all... -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes: > On Wed, Jul 23, 2014 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> A more robust fix would be to identify the para where the problem actually >> is and re-word it so that the link doesn't cross a *line* boundary (in >> either US or A4). That makes it safe as long as that particular para >> doesn't get reworded in future; whereas with what you did, addition or >> subtraction of a line anywhere in a pretty broad range could resurrect >> the issue. > Hmm. Good point. OTOH it only showed up in the backbranch (and only in > one of them), so I figured we might get away with it. > Have you figured out any way to actually track down which para has the > problem itself, or is it all manual work? My recollection is it takes a bit of detective work but you can generally figure it out by eyeballing the TeX input file around the complained-of line number. The first trick is that our makefiles think the TeX input file is temp and delete it on failure, so you need to ask for it to be built not the PDF file. The second trick is that the line number is not spot-on; the error seems to come out only when TeX decides where it's going to break the page, which it won't do until it has absorbed a few more lines than actually end up on the page. I think I've posted more details in some past thread on the issue ... oh, here: http://www.postgresql.org/message-id/9473.1296172647@sss.pgh.pa.us >> Of course, it would be a lot better if the toolchain didn't have this >> limitation (or at least managed to report it more usefully). I'm not >> holding my breath for that to happen though. > Yeah, they would probably have done it years ago if they were going to at all... IIRC there actually was a patch that purported to fix this a year or so ago, but it didn't help :-( regards, tom lane
Magnus Hagander <magnus@hagander.net> writes: > Have you figured out any way to actually track down which para has the > problem itself, or is it all manual work? Oh ... the TUG page now has a recipe for finding the problem less painfully, which I don't recall having seen before: http://ftp.tug.org/mail-archives/pdftex/2002-February/002216.html In short, you can add a "draft" option that lets PDF output get generated anyway, and then you can actually see exactly what link is getting split. regards, tom lane
I wrote: > Oh ... the TUG page now has a recipe for finding the problem less > painfully, which I don't recall having seen before: > http://ftp.tug.org/mail-archives/pdftex/2002-February/002216.html > In short, you can add a "draft" option that lets PDF output get generated > anyway, and then you can actually see exactly what link is getting > split. Unfortunately, that recipe seems to have little to do with current reality :-(. Perhaps there's a \usepackage{hyperref} somewhere in the style files JadeTeX provides, but it's sure not in the tex-pdf files we generate, so editing it isn't a convenient solution. What I did to locate the problem was to add some garbage text in the para you identified, so that the A4 PDF would build again, and then look at the output. The problem turns out to be in the *next* para, which in A4 format breaks like this: pg_relation_size accepts the OID or name of a table, index or toast table, and returns the on- disk size in bytes. Specifying ’main’ or leaving out the second argument returns the size of the main data fork of the relation. Specifying ’fsm’ returns the size of the Free Space Map (see Section 54.3) associated with the relation. Specifying ’vm’ returns the size of the Visibility Map (see Sec- tion 54.4) associated with the relation. Note that this function shows the size of only one fork; for most purposes it is more convenient to use the higher-level functions pg_total_relation_size or pg_table_size. So both the FSM and VM section-reference hyperlinks break across lines, and one or the other is falling across a page boundary in the problematic build. I think we'd better rearrange this para to avoid problems in future, especially in case somebody decides to invent more forks. I remember thinking that the possible options would look better if broken out as an itemizedlist anyway. Let me try that ... regards, tom lane
On 07/23/2014 06:31 AM, Magnus Hagander wrote: > > > Do we actually have any buildfarm boxes building the PDFs? And if so, > any idea why they didn't catch it? AFAIK, nobody's ever asked for such a thing. The docs optional step just builds the default docs target, which is simply the HTML docs. It should be possible, just a SMOC. cheers andrew
On Wed, Jul 23, 2014 at 10:15 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > On 07/23/2014 06:31 AM, Magnus Hagander wrote: >> >> >> >> Do we actually have any buildfarm boxes building the PDFs? And if so, >> any idea why they didn't catch it? > > > > AFAIK, nobody's ever asked for such a thing. The docs optional step just > builds the default docs target, which is simply the HTML docs. > > It should be possible, just a SMOC. I think it would be very useful to have. Given how long it takes to build not all the time, but running it every couple of days or weekly or so would be quite useful. Then we'd catch things earlier and not have to spend as much time trying to figure out exactly what broke... -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > I think it would be very useful to have. Given how long it takes to > build not all the time, but running it every couple of days or weekly > or so would be quite useful. Then we'd catch things earlier and not > have to spend as much time trying to figure out exactly what broke... I have a half-setup buildfarm job in the machine that powers guaibasaurus that's intended to build HTML docs every five minutes or so. I guess I could see about finishing that, and having it do the PDF build once a week or so. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Hi, On Wed, 2014-07-23 at 15:53 +0200, Magnus Hagander wrote: > I ended up splitting the paragraph in two in order to get the PDFs to > build. I've applied a patch for this to 9.0 only so we can keep > building PDFs. Thanks for looking at this -- you saved my time. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
On Wed, 2014-07-23 at 12:31 +0200, Magnus Hagander wrote: > Do we actually have any buildfarm boxes building the PDFs? And if so, > any idea why they didn't catch it? My jenkins does that, and I reported the problem here http://www.postgresql.org/message-id/1400206646.15189.3.camel@vanquo.pezone.net two months ago. So the missing step here not detecting the problem, but fixing it when we detect it.