I just added 20 cross sections and now my map fails to process with: converting scraps ... done making map ... done This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) entering extended mode (./data.tex (./th_enc.tex) (./th_texts.tex) (./th_resources.tex) (./th_fontdef.tex{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}) (./th_formdef.tex Runaway text? ! TeX capacity exceeded, sorry [main memory size=1000000]. l.47627 \PL{ 249.81 181.74 250.44 181.80 250.46 182.14 c}% If you really absolutely need more capacity, you can ask a wizard to enlarge me. Here is how much of TeX's memory you used: 292 strings out of 97341 2961 string characters out of 1211748 1000001 words of memory out of 1000000 Do I really need to change this (how?) or is it probably something else that has gone wrong? That 'runaway text?' looks suggestive. What I really need to know is how to debug it. I ran therion -d so now I have a /tmp/thTMPDIR full of mysterious stuff. Attached is data.tex from there, which seems likely to be relevant. Is that enough to determine what broke? The current full dataset is in svn at wookware.org, which MartinS now has access to. And whilst I'm here: I would also note that adding scraps in a 900-line file is almost unbearably slow on a 900Mhz machine. It feels like something in the code does a linear search so it gets slower and slower to add each line/item. ctrl-r produces about a 15-second wait. I supppose I should just have put all the x-sects in another file. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) ! TeX capacity exceeded, sorry [main memory size=1000000]. l.47627 \PL{ 249.81 181.74 250.44 181.80 250.46 182.14 c}%
Do I really need to change this (how?) or is it probably something else that has gone wrong? That 'runaway text?' looks suggestive.
This means that you have 1 MB of data in one scrap -- each scrap is processed separetely by pdftex. New sections should not influence it. (It might be possible that ancient pdftex version (1.21a) you are using does not flush the data to the pdf file after the scrap is processed and keeps all the data in the memory. Try to find whether the file th_formdef.tex reaches 1 MB on the problematic line 47627. If this is the case try to update pdftex.) You may also increase the memory pdftex is using in the file texmf/web2c/texmf.cnf by redefining the variable main_memory.
What I really need to know is how to debug it. I ran therion -d so now I have a /tmp/thTMPDIR full of mysterious stuff. Attached is data.tex from there, which seems likely to be relevant. Is that enough to determine what broke?
th_formdef.tex
And whilst I'm here: I would also note that adding scraps in a 900-line file is almost unbearably slow on a 900Mhz machine. It feels like something in the code does a linear search so it gets slower and slower to add each line/item. ctrl-r produces about a 15-second wait.
I supppose I should just have put all the x-sects in another file.
It might be a good idea to draw one scrap with sections in one file, especially on the slow computer... Regards, Martin
On 12/28/06, Martin Budaj <m.budaj@gmail.com> wrote:
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) ! TeX capacity exceeded, sorry [main memory size=1000000]. l.47627 \PL{ 249.81 181.74 250.44 181.80 250.46 182.14 c}%
Do I really need to change this (how?) or is it probably something else that has gone wrong? That 'runaway text?' looks suggestive.
This means that you have 1 MB of data in one scrap -- each scrap is processed separetely by pdftex.
Therion 0.4.0 automatically creates a scrap containing centreline if no map is selected in the thconfig file. This scrap can easily exceed 1 MB in size in large caves (e.g. 4.5 MB for Dead Bats Cave). You may avoid its creation by selecting any of defined map objects in 'export map' command. Martin
On 2006-12-29 22:14 +0100, Martin Budaj wrote:
On 12/28/06, Martin Budaj <m.budaj@gmail.com> wrote:
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) ! TeX capacity exceeded, sorry [main memory size=1000000]. l.47627 \PL{ 249.81 181.74 250.44 181.80 250.46 182.14 c}%
Do I really need to change this (how?) or is it probably something else that has gone wrong? That 'runaway text?' looks suggestive.
This means that you have 1 MB of data in one scrap -- each scrap is processed separetely by pdftex.
Therion 0.4.0 automatically creates a scrap containing centreline if no map is selected in the thconfig file. This scrap can easily exceed 1 MB in size in large caves (e.g. 4.5 MB for Dead Bats Cave). You may avoid its creation by selecting any of defined map objects in 'export map' command.
I have selects in my thconfig file: #Map(s) to include in output select toplevelplan@terikan select midlevelplan@terikan select aboveriverplan@terikan select riverlevelplan@terikan which I assume is what you mean by the above? And the underlying data hasn't changed for months so I don't think this is the problem. The one thing that seems to make a differnce is base-scale. If i change it from 1:1000 to 1:2000 then the error changes. Now I get: [319] [320] [321] [322] [323] [324] [325] [326] [327] [328] [Warning: text scaled down to fit the path in scrap soundriver2_s4@terikan] [329] [330] [331] [332] [333]
0.7593dirs4+222.06123 ! Improper transformation argument. <to be read again> endgroup <to be read again> ) <forever> ...+if.par:0.333*fi.l*unitvector(dir(a)) );cas:=cas+mojkrok;par:=no...
l_slope->...;exitif.cas>dlzka+0.3u+(krok/3);endfor ;if(EXPR1)=1:pickup.PenC;d... l.33489 ...2,225.273,33.9682),(3,208.773,33.5305)) ;
0.7593lengths4+36.69966 ! Undefined x coordinate has been replaced by 0. <to be read again> ; <forever> ...f.par:0.333*fi.l*unitvector(dir(a))); cas:=cas+mojkrok;par:=not....
l_slope->...;exitif.cas>dlzka+0.3u+(krok/3);endfor ;if(EXPR1)=1:pickup.PenC;d... l.33489 ...2,225.273,33.9682),(3,208.773,33.5305)) ; [334] I don't know if that is a clue at all. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
Therion 0.4.0 automatically creates a scrap containing centreline if no map is selected in the thconfig file. This scrap can easily exceed 1 MB in size in large caves (e.g. 4.5 MB for Dead Bats Cave). You may avoid its creation by selecting any of defined map objects in 'export map' command.
I have selects in my thconfig file: #Map(s) to include in output select toplevelplan@terikan select midlevelplan@terikan select aboveriverplan@terikan select riverlevelplan@terikan
which I assume is what you mean by the above?
yes, if toplevelplan@terikan and others are maps, not surveys
And the underlying data hasn't changed for months so I don't think this is the problem.
right, but therion changed from 0.3.10 to 0.4.0 -- the automatic generation of scrap with all centreline data is a new feature
The one thing that seems to make a differnce is base-scale. If i change it from 1:1000 to 1:2000 then the error changes. Now I get:
...
[329] [330] [331] [332] [333]
l_slope->...;exitif.cas>dlzka+0.3u+(krok/3);endfor ;if(EXPR1)=1:pickup.PenC;d... l.33489 ...2,225.273,33.9682),(3,208.773,33.5305))
It is some issue with the slope symbol definition in small scale maps -- I'll check it. Note that it occurs earlier than the out-of-memory problem (line 33489). Martin
On 2007-01-02 11:52 +0100, Martin Budaj wrote:
Therion 0.4.0 automatically creates a scrap containing centreline if no map is selected in the thconfig file. This scrap can easily exceed 1 MB in size in large caves (e.g. 4.5 MB for Dead Bats Cave). You may avoid its creation by selecting any of defined map objects in 'export map' command.
I have selects in my thconfig file: #Map(s) to include in output select toplevelplan@terikan select midlevelplan@terikan select aboveriverplan@terikan select riverlevelplan@terikan
which I assume is what you mean by the above?
yes, if toplevelplan@terikan and others are maps, not surveys
they are yes.
And the underlying data hasn't changed for months so I don't think this is the problem.
right, but therion changed from 0.3.10 to 0.4.0 -- the automatic generation of scrap with all centreline data is a new feature
OK. But this dataset was being processed quite happily with 0.4.0, until I added some more cross sections (and some areas). It seems that either one of these changes made something genuinely too big, or there was some error introduced which is making tex run out of memory.
The one thing that seems to make a differnce is base-scale. If i change it from 1:1000 to 1:2000 then the error changes. Now I get:
...
[329] [330] [331] [332] [333]
l_slope->...;exitif.cas>dlzka+0.3u+(krok/3);endfor ;if(EXPR1)=1:pickup.PenC;d... l.33489 ...2,225.273,33.9682),(3,208.773,33.5305))
It is some issue with the slope symbol definition in small scale maps -- I'll check it. Note that it occurs earlier than the out-of-memory problem (line 33489).
Ah, OK. so we may have both :-; Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
On 1/2/07, Wookey <wookey@aleph1.co.uk> wrote:
I have selects in my thconfig file: #Map(s) to include in output select toplevelplan@terikan select midlevelplan@terikan select aboveriverplan@terikan select riverlevelplan@terikan
which I assume is what you mean by the above?
yes, if toplevelplan@terikan and others are maps, not surveys
they are yes.
are you sure that they are known to therion? in case of unexisting maps therion issues just the warning "survey not fond" in the log file. i selected select overall-map@Mulu and got a pdf file without problems
And the underlying data hasn't changed for months so I don't think this is the problem.
right, but therion changed from 0.3.10 to 0.4.0 -- the automatic generation of scrap with all centreline data is a new feature
OK. But this dataset was being processed quite happily with 0.4.0, until I added some more cross sections (and some areas). It seems that either one of these changes made something genuinely too big, or there was some error introduced which is making tex run out of memory.
randomised areas can produce quite large amount of data, especially sand and debris. if you upload the recent dataset to your server, i might check where the problem is martin p.s. when processing your *.svx using cavern i got 4 errors concerning dates -- mixed day/month/year figures
On 2007-01-02 14:23 +0100, Martin Budaj wrote:
On 1/2/07, Wookey <wookey@aleph1.co.uk> wrote:
I have selects in my thconfig file: #Map(s) to include in output select toplevelplan@terikan select midlevelplan@terikan select aboveriverplan@terikan select riverlevelplan@terikan
which I assume is what you mean by the above?
yes, if toplevelplan@terikan and others are maps, not surveys
they are yes.
are you sure that they are known to therion? in case of unexisting maps therion issues just the warning "survey not fond" in the log file.
Pretty sure. I have processed terikan_only.th hundreds of times. It was selecting the above maps. I do have the above problem at the benarat level of the data, but not at the terikan level.
i selected select overall-map@Mulu and got a pdf file without problems
This is at the top level thconfig file? Interesting - I can do that OK too, until right at the end where it is 'writing MuluWalls.3d' and I get a segfault.
And the underlying data hasn't changed for months so I don't think this is the problem.
right, but therion changed from 0.3.10 to 0.4.0 -- the automatic generation of scrap with all centreline data is a new feature
OK. But this dataset was being processed quite happily with 0.4.0, until I added some more cross sections (and some areas). It seems that either one of these changes made something genuinely too big, or there was some error introduced which is making tex run out of memory.
randomised areas can produce quite large amount of data, especially sand and debris.
if you upload the recent dataset to your server, i might check where the problem is
It is in svn at svn://wookware.org/mulusurvery I think martins has told you the password, or I can send you mail. I have now turned up my TeX memory to 2000000 and it all processes fine. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
On 2006-12-28 20:38 +0100, Martin Budaj wrote:
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) ! TeX capacity exceeded, sorry [main memory size=1000000]. l.47627 \PL{ 249.81 181.74 250.44 181.80 250.46 182.14 c}%
Do I really need to change this (how?) or is it probably something else that has gone wrong? That 'runaway text?' looks suggestive.
This means that you have 1 MB of data in one scrap -- each scrap is processed separetely by pdftex. New sections should not influence it. (It might be possible that ancient pdftex version (1.21a) you are using does not flush the data to the pdf file after the scrap is processed and keeps all the data in the memory. Try to find whether the file th_formdef.tex reaches 1 MB on the problematic line 47627.
line 47627 is 0x17A850 or 1550416 bytes i.e. ~1.5Mb. Updating the pdftex version is a bit tricky. I ought to try texlive though, which I think is supposed to be more modern.
If this is the case try to update pdftex.)
You may also increase the memory pdftex is using in the file texmf/web2c/texmf.cnf by redefining the variable main_memory.
OK. I tried this but I still get the same error: ! TeX capacity exceeded, sorry [main memory size=1000000]. even though /etcx/texmf/texmf.cnf now has: main_memory = 2000000 % words of inimemory available; also applies to inimf&mp Why is it ignoring me - there is some other setting (there are lots in there like: main_memory.context = 1500000 main_memory.mpost = 1500000 but no others are 1000000 Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
You may also increase the memory pdftex is using in the file texmf/web2c/texmf.cnf by redefining the variable main_memory.
OK. I tried this but I still get the same error: ! TeX capacity exceeded, sorry [main memory size=1000000].
even though /etcx/texmf/texmf.cnf now has: main_memory = 2000000 % words of inimemory available; also applies to inimf&mp
Why is it ignoring me
You have probably modified not the same config file as texlive is reading. My texlive installation on windows has both texmf/web2c/texmf.cnf and texmf-var/web2c/texmf.cnf of which the former is ignored... Martin
participants (3)
-
Martin Budaj -
Philip Schuchardt -
Wookey