[mkgmap-dev] Mkgmap appears to hang on some split files
From Chris Miller chris.miller at kbcfp.com on 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
- Previous message: [mkgmap-dev] Mkgmap appears to hang on some split files
- Next message: [mkgmap-dev] Mkgmap appears to hang on some split files
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list