forwarded problem of 1.40.7 on powerpc
Hi guys,
See below for a bug in 1.40.7 as posted on the context list.
As I wrote there, it looks like an endianness issue because
300000 >> 16 == 5
Either that, or some object has a different size on ppc, but that
seems unlikely to me.
I am hoping someone has a powerpc to try and sort this out.
Best wishes,
Taco
-------- Original Message --------
Subject: Re: [NTG-context] bib module and pdftex 1.40.7: Virtual memory
exhausted using MiKTeX-2.7
Date: Wed, 27 Feb 2008 10:26:46 +0100
From: Thomas A. Schmitz
Just the other day, I encountered a mysterious error which may or may not be related. I upgraded to pdftex 1.40.7 on all my boxes. This was smooth on my intel-macs (OS X 10.5.2). On my powerpc-mac, I got a "TeX capacity exceeded!" error with 1.40.7 for a file that compiled fine with 1.40.5. I tried several times: all I did was dropping the pdftex binary and pdftex.pool in place, rebuilding th format and compiling the file. Compilation was smooth with 1.40.5 and consistently failed with 1.40.7 (which I compiled and recompiled without any special flags). I haven't pursued the matter for the moment and just went back to 1.40.5, but I'm wondering if these problems are related. Do you have a test file ?
Sorry, it took me a while because this is the computer in my office, from which I;ve been away for a while. I think I nailed it down: if I try to include a pdf image into a ConTeXt document \starttext \externalfigure[Logo][width=56mm,height=20mm] \stoptext (with any pdf file) I get this error: <./Logo.pdf ! TeX capacity exceeded, sorry [PDF object stream buffer=5]. \dogetTPDfiguresize ...geBox {\@@DriverImageFile } \xdef \PDFimagereference {... \doanalyzefiguredimensionsinternal ...tfiguresize \setanalyzedfiguredimensio... <argument> ...}\doanalyzefiguredimensionsinternal \doanalyzefiguredimensions... \firstoftwoarguments #1#2->#1 \dododoanalyzeunknownfiguretype ...guredimensions \fi \next2 ...dododoanalyzeunknownfiguretype {pdf}{#1} \doprocesscommaitem ... l.4 ! ==> Fatal error occurred, no output PDF file produced! The pdf file is OK; this error only occurs with pdftex 1.40.7 on powerpc (OS X, 10.5.2). The same file compiles fine with luatex on powerpc and intel pdftex 1.40.5 on powerpc and intel pdftex 1.40.7 on OS X intel All best Thomas ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
Taco Hoekwater wrote:
Hi guys,
See below for a bug in 1.40.7 as posted on the context list. As I wrote there, it looks like an endianness issue because
300000 >> 16 == 5
Sorry about this, of course it isn't. But I still suspect an endianness issue. Best wishes, Taco
2008/2/27, Taco Hoekwater
Sorry about this, of course it isn't. But I still suspect an endianness issue.
if s > sup_pdf_os_buf_size - pdf_ptr then overflow("PDF object stream buffer", pdf_os_buf_size); I suspect someone fiddled with --disable-largefile. :-( pdf_ptr is a longinteger, i.e. off_t. s is an integer, sup_pdf_os_buf_size is just a const. Surely s doesn't have to be a longinteger? Best Martin
Martin Schröder wrote:
2008/2/27, Taco Hoekwater
: Sorry about this, of course it isn't. But I still suspect an endianness issue.
if s > sup_pdf_os_buf_size - pdf_ptr then overflow("PDF object stream buffer", pdf_os_buf_size);
I suspect someone fiddled with --disable-largefile. :-( pdf_ptr is a longinteger, i.e. off_t. s is an integer, sup_pdf_os_buf_size is just a const. Surely s doesn't have to be a longinteger?
perhaps the function is accidentally called with a longinteger argument?
On Wed, 27 Feb 2008, Martin Schröder wrote:
2008/2/27, Taco Hoekwater
: Sorry about this, of course it isn't. But I still suspect an endianness issue.
if s > sup_pdf_os_buf_size - pdf_ptr then
possibly this helps, by avoiding the subtraction: if s + pdf_ptr > sup_pdf_os_buf_size then
overflow("PDF object stream buffer", pdf_os_buf_size);
iirc we already had a similar looking problem that could be "solved" by this type of change. Regards, Hartmut
participants (3)
-
Hartmut Henkel
-
Martin Schröder
-
Taco Hoekwater