[mkgmap-dev] Corrupt img directory on large image files

Tue Oct 26 11:09:02 BST 2010

Hello

> Phenomenon:
> I built an full-blown img from a single 46Mb source, let's say

This is rather large for a single map tile.

> Suggested code changes:
> In package uk.me.parabola.imgfmt.sys
> in file directory.java
> in function void sync()
> replace: int forHeader = (blocks + (blockSize - 1)) / blockSize;
> by: int forHeader = (blocks + DirectoryEntry.SLOTS_PER_ENTRY -
> 1)/DirectoryEntry.SLOTS_PER_ENTRY;
> The calculation of forHeader is obviously wrong what in turn causes the
> position needed for other blocks to be wrong too.

Yes that does appear to be wrong.

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.

> 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
will hit the total number of blocks limit after only a few entries in
the second block.

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.

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.

> If someone tells me a place were I could store the sample source I will
> do so.

> I've no experience in respect of the code change procedures, so could
> one of you guys check-in the changes?

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.

> By the way - I wonder why nobody else remarked this before.

Usually you hit another limit first before the block limit is
reached.  And if the file was somewhat bigger then the check in
BlockManager would have been hit, but it is a bit strange that this
hasn't been reported before.

..Steve