[mkgmap-dev] Corrupt img directory on large image files
From Steffen Neumann sn at litotes.de on Tue Oct 26 14:21:40 BST 2010
>> Phenomenon: >> I built an full-blown img from a single 46Mb source, let's say > >This is rather large for a single map tile. Yes, it is. But should work properly or terminate with an error. >Anyway the real bug is that this should have been caught earlier on. >There are a couple of places where sizes are checked, my first >impression is that the one in BlockManager needs changing. Where should it be caught? The BlockManger has a single limitation and this is maxBlock. As long as you not hit it, everything is fine. The base value in all setMaxBlock() calls is params.getReservedDirectoryBlocks(). And this seems to be always 2. > >> 2 lines later there's an assert to ensure a forHeader of 1. This could >> be removed. The rest of the code seems to be aware of multiple header >> blocks. > >I'm not sure that more than one block is allowed as I've not seen >any files that have more than one. It is also not very useful as you It's probably out of spec. I don't know. >will hit the total number of blocks limit after only a few entries in >the second block. Yes, after 34 entries. > >I think that another changes would be needed as we only leave room for >one block in the calculations of how big the header is I think. I tried out different constellations and it seems to work. The position of other directory blocks is based on the number of header blocks calculated above (the wrong formula). In contrast - the calculation of data block position seems to be based on the correct formula in Map.close(). So I suggest to take-over my approach as quick fix. > > >The gmapsupp code is able to automatically adjust the block size so >that the directory does not overflow. This was never done for single >.img files, although it would be good for completeness. >The code should really be combined, so there are not two different >implementations. Oh yes, this could be the 'all singing all dancing' solution but for the time being a quick fix should work. The essential question is: Is it compatible to MapSource? >If you can create a patch you can post it to the list, otherwise zip >up the affected source files and upload to files.mkgmap.org.uk or >anywhere else you have access to. Done. Please find it attached. best Steffen ___________________________________________________________ WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2 -------------- next part -------------- A non-text attachment was scrubbed... Name: CorruptDirectory.patch Type: application/octet-stream Size: 911 bytes Desc: not available Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20101026/2d434077/attachment.obj
- Previous message: [mkgmap-dev] Corrupt img directory on large image files
- Next message: [mkgmap-dev] Corrupt img directory on large image files
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list