[mkgmap-dev] Mkgmap appears to hang on some split files

Mon Sep 28 15:57:29 BST 2009

Ah ok that makes more sense. A crash dump usually indicates the VM has a 
bug or has died 'violently' (as is the case here). A stack dump on the other 
hand is produced by the VM and shows you what Java code is currently executing.

It looks like you are running on a dual CPU box (two dual-core Xeons?). Are 
you also saying that you only hit the problem sometimes; you can rerun the 
same command again and it will run to completion just fine? Also, you say 
mkgmap is hung at 100% CPU. Is that all 4 cores, or just one of them?

One thing dual CPU boxes can be good at is highlighting otherwise obscure 
multithreaded bugs. I'm not familiar with the threading in mkgmap but possibly 
you're hitting a race condition in the code (eg an unsynchronized HashMap 
can behave like this). I've just had a quick glance at the code however and 
can't see anything obvious - there's very little shared state and what little 
there is appears to be synchronized OK. Which makes me wonder if, as Steve 
points out, the problem lies with your VM rather than mkgmap. Definitely 
worth trying another (or newer version of the existing) VM.

Thanks for getting a stack dump. It's interesting, mkgmap is inside native 
array-copying code while parsing an osm file. There's only one worker thread 
running at this point, I'm surprised to see it hanging there. Can you try 
running with --max-jobs=1 to see if the problem still happens?

Chris

L> Thanks Steve, Chris,
L> 
L> The error files were produced using kill -4 <pid>. Kill -1 till -3
L> had no effect on the process. Just switching to using Sun Java is
L> probably the easy way out, but I reckon it's interesting to find out
L> what happened :-), so next time I'll try jstack before killing the
L> process.
L> 
L> Sorry that the VM crash dumps aren't useful.
L> 
L> Steve Ratcliffe wrote:
L> 
>> On 28/09/09 13:53, Lambertus wrote:
>> 
>>> It happened again, this time straight from the commandline while
>>> trying to render the three failed tiles at once by providing r2228
>>> the *.osm.gz parameter... Stack dump is attached.
>>> 
>> Those hs_err_* files were not what I was expecting at all.  You
>> normally get one of those when the java process itself crashes and
>> that is always a bug in java and not the application.  How exactly
>> did you provoke it into dropping that file?
>> 
>> I see from them that you are using the openjdk with Ubuntu,
>> so I tried openjdk on my Fedora machine and didn't get a problem but
>> then it is 32bit and has a higher build number so probably has
>> different (perhaps fewer ;) bugs.
>> If you can I'd try the Sun jdk instead to see if that is any
>> different.
>> 
>> ..Steve