Hi Lambertus, What you have attached is a crash dump from the JVM, not a stack dump of the (running) Java application. How are you getting that file? If it's being generated as the result of you killing the process, then it's not useful. You need to instead try and get a stack dump output by following Steve's directions. Did you try pressing CTRL-\ in the hung terminal window, or running "kill -QUIT <pid>", or "kill -3 <pid>", or "jstack <pid>"? Doing so should output information about the current state of mkgmap (what threads are running and what they're doing, etc) which should help diagnose the problem. Chris L> It happened again, this time straight from the commandline while L> trying to render the three failed tiles at once by providing r2228 L> the *.osm.gz parameter... Stack dump is attached. L> L> r1067 finishes the same test normally (with errors). Then I tried L> r2228 again a few times and it finishes normally (with errors) as L> well. L> L> Aaargh! L> L> http://planetosm.oxilion.nl/~lambertus/73240155.osm.gz L> http://planetosm.oxilion.nl/~lambertus/73240185.osm.gz L> http://planetosm.oxilion.nl/~lambertus/73240240.osm.gz L> L> Lambertus wrote: L>
Thanks for having a look at it Steve. Stackdumps are attached. OS = Ubuntu linux 9.04 64bit. LANG variable = en_US.UTF-8. Java version = 1.6.0_0, OpenJDK RE 6b14-1.4.1-@ubuntu11, OpenJDK 64bit server VM 14.0-b88 mixed-mode.
I've tried r1067 from the commandline which fails to render the tiles (out of memory) but exits 'normally' with a result code (which is what I want). Then I tried version 1022 and 1028 from the commandline and both finished quickly as well. So I'm starting to think it might have something to do with the way PHP passthru() executes these commands (I've written a PHP script that recursively splits and renders tiles until all areas are rendered). But a quick Google search did not bring up anything.
Steve Ratcliffe wrote:
Hi Lambertus
On 28/09/09 08:36, Lambertus wrote:
While trying to get a new world map update out the door I noticed that Mkgmap sometimes hangs on an OSM data file produced with Splitter. When this happens the CPU is at 100% constantly for hours (e.g. all night) until I kill the process. The problem occurs in r1222 and also r1228.
I ran the command line you gave with 1222 and 1228 on both the files and it completed in about a minute. So no hang for me, and I'm going to have to ask a few questions to have any idea.
Is there any version where it works without hanging for you? What OS was it running on? What is the LANG variable set to (if running on Linux)? Could you send a stack dump when it is stuck, since it completes after 1 minute for me, probably waiting five minutes is more than enough to know that it is stuck.
You can get a stack trace using typing ctrl-\ or using kill -QUIT on linux and on windows ctrl-break is supposed to work but I wouldn't know. Another way that works the same everywhere is to use jstack. Use jps to get the process id of the running processes and call jstack with that id. jstack and jps come with JDK download of java from sun and probably other places too. Thanks
..Steve