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

Mon Sep 28 16:38:46 BST 2009

The box is a laptop with a single Intel P8600 CPU (dual core Penryn) and 
when the process hangs it's just 1 core that is at 100% (I use only one 
core so I can render America and Eurasia in parallel).

I've tried the --max-jobs=1 parameter a few times and got it to hang, 
stackdump (which seems identical to the earlier one I posted) is 
attached. Funny thing is that the process produces a stackdump with kill 
-3 <pid> but it continues to run at 100%. Kill -4 is needed to persuade 
it to really stop.

Chris Miller wrote:
> 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
> 
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Mkgmap Java VM stackdump 2.txt
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090928/84f8287e/attachment.txt 