[maemo-developers] [maemo-developers] Tinymail using mmap() gets killed by the kernel of the device

[From: Eero Tamminen]

Hi,

On Mon, Jul 17, 2006 at 11:00:01AM +0200, Philip Van Hoof wrote:
> > > I cannot change these "to, from nor subject" pointers. These are used
> > > in thousands of lines of Evolution code that I don't want to change.
> > 
> > There's no need to align access to chars.  Is there something that accesses
> > the saved data as shorts, longs (ints), floats or doubles? Or casts the
> > char pointers e.g. into int *?  (use -Wcast-align)
> 
> Yes. But I already did something to make sure that access is correct.
> 
> It's in the patch. Search for "get_unaligned_u32"

Why the code changes everything saved to network order?
The byteorder doesn't change unless you move to a different
CPU architecture and I would assume mmap files to be
quite specific for one machine. :-)


> http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment03.diff

At least this one is broken:
+#define CFU_ENCODE_T(type) \
+int \
+camel_file_util_encode_##type(FILE *out, type value) \
+{ \
+	return camel_file_util_encode_fixed_int32 (out, (guint32) value); \
 }

The original code was using sizeof(type), not blindly assuming
it to be guint32.



These changes are a bit strange, they change the semantics of the code:
 
-	if (camel_file_util_decode_fixed_int32(in, &cns->version) == -1)
-		return -1;
+	cns->version = g_ntohl(get_unaligned_u32(s->filepos)); s->filepos += 4;

-	if (camel_file_util_decode_fixed_int32(in, &cns->high) == -1
-	    || camel_file_util_decode_fixed_int32(in, &cns->low) == -1)
-		return -1;
+	cns->high = g_ntohl(get_unaligned_u32(s->filepos)); s->filepos += 4;
+	cns->low = g_ntohl(get_unaligned_u32(s->filepos)); s->filepos += 4;


Btw. something like this:
+	if (lena % G_MEM_ALIGN)
+		lena += G_MEM_ALIGN - (lena % G_MEM_ALIGN);

Might be slower than just aligning always:
  lena = (lena + (G_MEM_ALIGN-1)) & ~(G_MEM_ALIGN-1);

Which can be nicely wrapped in a macro:
        /* assume "var" is either char/short/int/long or pointer to char
	 * so that it doesn't need to cast into something which
	 * increments happen in units of one
	 */
	ALIGN(var) (var = (var + (G_MEM_ALIGN-1)) & ~(G_MEM_ALIGN-1))




> Yet the patch still isn't working on ARM (and I don't have a debug
> infrastructure, unless somebody can explain me how to set it up using
> some emulator -- like qemu? --).

You can request the kernel to give warnings about unligned access.
I'm not sure whether you need to re-compile kernel for that or
is there a /proc entry for that.

Some other Gotchas on ARM are sign extensions.  You need to watch
out for compiler warnings about comparisons where chars are of
different signedness I think.


	- Eero