public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven.eckelmann@gmx.de>
To: b.a.t.m.a.n@open-mesh.net
Subject: Re: [B.A.T.M.A.N.] Debug Malloc Problem
Date: Wed, 27 May 2009 00:13:08 +0200	[thread overview]
Message-ID: <200905270013.12447.sven.eckelmann@gmx.de> (raw)
In-Reply-To: <4313f3060905261150o6c9fe82at6dd40d26456ac03a@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

On Tuesday 26 May 2009 20:50:56 Nathan Wharton wrote:
> I added the following patch:
> =========================================
> --- batmand-r1269/batman/allocate.c     2009-05-20 13:54:18.000000000 -0500
> +++ batmand-r1269.mod/batman/allocate.c 2009-05-26 12:25:07.000000000 -0500
> @@ -206,6 +206,10 @@
>        struct chunkHeader *chunkHeader;
>        struct chunkTrailer *chunkTrailer;
>        unsigned char *chunk;
> +       uint32_t remainder = length % 4;
> +
> +       if (remainder > 0)
> +         length += 4 - remainder;
>
>  /*     printf("sizeof(struct chunkHeader) = %u, sizeof (struct
> chunkTrailer) = %u\n", sizeof (struct chunkHeader), sizeof (struct
> chunkTrailer)); */
Please don't introduce more magic numbers. If you need an alignment on integer 
granularity then please use sizeof(int) instead of a simple constant.
The rest looks quite good and logical. I assumed that the only architecture 
without automatic catching of alignment problems is mips with load operators 
to the fp registers (never had such problems on simple arm machine nor could I 
produce that problem on them). Is there any other documentation about such 
problems on xscale or can you proof this with an test program (malloc 6 byte, 
write uint32_t to first 4 byte, write another uint32_t to byte 2-5, compare 
bytes with input - don't forget to set it volatile)? Your current proof if 
concept test only shows that the "overriden" bytes will not get overriden 
after moving them some bytes higher.

=========================================
#include <stdio.h>
#include <stdlib.h>

#define x_moved(pos) ((int*)&x[pos])[0]
static const int value1 = 0x01234567;
static const int value2 = 0x89abcdef;

int main() {
	volatile char *x = (char*)malloc(sizeof(int) * 2);
	x_moved(0) = value1;
	x_moved(2) = value2;

	if (x_moved(2) != value2) {
		printf("ERROR Value: ");
	} else {
		printf("Value: ");
	}
	printf("%x %x\n", x_moved(0) , x_moved(2));

	free(x);
	return 0;
}
=========================================


Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

  reply	other threads:[~2009-05-26 22:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26 18:48 [B.A.T.M.A.N.] Debug Malloc Problem Nathan Wharton
2009-05-26 18:50 ` Nathan Wharton
2009-05-26 22:13   ` Sven Eckelmann [this message]
2009-05-27  0:06     ` Nathan Wharton
2009-05-27  9:28       ` Marek Lindner
2009-05-27 14:20     ` Nathan Wharton
2009-05-27 16:07       ` Nathan Wharton
2009-05-27 16:16       ` Sven Eckelmann
2009-05-27 16:21         ` Nathan Wharton
2009-05-27 16:35           ` Nathan Wharton
2009-05-27 17:13             ` Sven Eckelmann
2009-05-27 17:21               ` Nathan Wharton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905270013.12447.sven.eckelmann@gmx.de \
    --to=sven.eckelmann@gmx.de \
    --cc=b.a.t.m.a.n@open-mesh.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox