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 --]
next prev parent 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