[Tilesathome] Some First Day Stats

[Jochen Frieling]

Hi,

> Brent Easton wrote:
> > One problem that needs to be addressed is that some tile sets can not be
> rendered by all machines, depending on the amount of RAM installed versus
> the complexity of the tile..
> >
> > This is a known problem with Inkscape and my testing with Batik
> indicates the same problem. I have 1GB of RAM and can render most tilesets
> successfully. However, once a tile reaches a certain complexity (e.g. around
> Rotterdam), then it is not possible to render it successfully on a 1GB machine -
> thrashing sets in, %cpu drops off to 0 and no work is done. Under these
> cirumstances, Inkscape tends to crash, while Batik keeps going, but never
> finishes the tile.
> I had the same issue (2GB, Linux). After patching the tilesGen.pl
> 
> -    my $Cmd = sprintf("%s \"%s\" tr %s %s > \"%s\"",
> +    my $Cmd = sprintf("%s \"%s\" tr --maxdepth 30000 %s %s > \"%s\"",}}
> 
> (line 956 or so)
> 
> the rendering of complex tiles worked. I was seeing this hint on
> Tilesathome or Talk-de recently. Maybe someone could give this a try.

Well, incidentally, right at this moment, my t at h client crashed, as it
was given the Rotterdam tile 2097,1351 :-)

I have 2GB RAM and am working with --maxdepth 20000. (I'm the one who
initially proposed that, and my xmlstarlet never complained again since
using this setting.)
The problem here is not xmlstarlet but inkscape.
Installed is 0.45.1-1 from Debian unstable and it crashed as follows:

[#5   0% jobinit] Doing tileset 2097,1351 (area around 52.079498,4.350586)
[#5   0% default] Rendering...                        sh: line 1: 29498
Aborted                 LC_ALL=C nice -n10 "inkscape" -z -w 256 -h 256
--export-area=0.000000:0.000000:878.900000:877.808258
--export-png="/tmp/25380.png_part" "/tmp/output-25380-z12.svg"
>/tmp/25380.stdout 2>/tmp//25380.stderr
ERROR
  The following command produced an error message:
  LC_ALL=C nice -n10 "inkscape" -z -w 256 -h 256
  --export-area=0.000000:0.000000:878.900000:877.808258
  --export-png="/tmp/25380.png_part" "/tmp/output-25380-z12.svg" >
  /tmp/25380.stdout
  Debug output follows:
  |
  | (inkscape:29498): Gdk-CRITICAL **: gdk_display_list_devices: assertion   `GDK_IS_DISPLAY (display)' failed
  | ** (inkscape:29498): WARNING **: GC Warning: Header allocation failed:   Dropping block.
  |
  |
  | ** (inkscape:29498): WARNING **: GC Warning: Out of Memory!  Returning   NIL!
  |
  | terminate called after throwing an instance of 'std::bad_alloc'
  |   what():  std::bad_alloc
  |
  | Emergency save activated!
  | Emergency save completed. Inkscape will close now.
  | If you can reproduce this crash, please file a bug at www.inkscape.org
  | with a detailed description of the steps leading to the crash, so we can fix it.
  | ** Message: Error: Inkscape encountered an internal error and will close now.
  |

Additional info about the Error(s):


[#5   0% default] LC_ALL=C nice -n10 "inkscape" -z -w 256 -h 256
--export-area=0.000000:0.000000:878.900000:877.808258
--export-png="/tmp/25380.png_part" "/tmp/output-25380-z12.svg" >
/tmp/25380.stdout failed
[#5   2% default] Splitting /tmp/25380.png_part (2 x 1)... Can't use an
/undefined value as a symbol reference at /usr/lib/perl5/GD/Image.pm line
175.


The funny thing is, all of the RAM (2GB) gets eaten up by inkscape,
but none of the the swap space is touched at all. Right at the moment
of using 2GB RAM, it crashed.
Shouldn't Linux memory management use swap space just like RAM?
Maybe this exposes a problem in inkscape, not being able to use swap
correctly, or the like.

Well, that's all I can say about this issue.
At least be assured that xmlstarlet will not choke on its job
with --maxdepth 20000 and the current complexities.
Though there haven't been any reports of xmlstarlet memory requirements
when activating high recursion depths.
 
Greetings,
Jochen Frieling


-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer