diff options
author | kpfleming <kpfleming@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-07-11 14:16:15 +0000 |
---|---|---|
committer | kpfleming <kpfleming@f38db490-d61c-443f-a65b-d21fe96a405b> | 2008-07-11 14:16:15 +0000 |
commit | 89fb9f202a23fd1fc6c2db8f0c913565938f9918 (patch) | |
tree | dbaf76e9988dd1fd0cad9a9ee1422340028402a6 /main/astmm.c | |
parent | 2da7c9d0dc67aad3f5081729854fba95372e0ec8 (diff) |
Merged revisions 129966 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r129966 | kpfleming | 2008-07-11 09:03:52 -0500 (Fri, 11 Jul 2008) | 5 lines
fix a flaw found while experimenting with structure alignment and padding; low-fence checking would not work properly on 64-bit platforms, because the compiler was putting 4 bytes of padding between the fence field and the allocation memory block
added a very obvious runtime warning if this condition reoccurs, so the developer who broke it can be chastised into fixing it :-)
........
r129967 | kpfleming | 2008-07-11 09:03:52 -0500 (Fri, 11 Jul 2008) | 5 lines
simplify calculation
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@129968 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'main/astmm.c')
-rw-r--r-- | main/astmm.c | 20 |
1 files changed, 19 insertions, 1 deletions
diff --git a/main/astmm.c b/main/astmm.c index f14ab8bdc..04a19037d 100644 --- a/main/astmm.c +++ b/main/astmm.c @@ -30,6 +30,7 @@ ASTERISK_FILE_VERSION(__FILE__, "$Revision$") #include "asterisk/paths.h" /* use ast_config_AST_LOG_DIR */ +#include <stddef.h> #include <time.h> #include "asterisk/cli.h" @@ -63,14 +64,26 @@ enum func_type { static FILE *mmlog; +/* NOTE: Be EXTREMELY careful with modifying this structure; the total size of this structure + must result in 'automatic' alignment so that the 'fence' field lands exactly at the end of + the structure in memory (and thus immediately before the allocated region the fence is + supposed to be used to monitor). In other words, we cannot allow the compiler to insert + any padding between this structure and anything following it, so add up the sizes of all the + fields and compare to sizeof(struct ast_region)... if they don't match, then the compiler + is padding the structure and either the fields need to be rearranged to eliminate internal + padding, or a dummy field will need to be inserted before the 'fence' field to push it to + the end of the actual space it will consume. Note that this must be checked for both 32-bit + and 64-bit platforms, as the sizes of pointers and 'size_t' differ on these platforms. +*/ + static struct ast_region { struct ast_region *next; + size_t len; char file[64]; char func[40]; unsigned int lineno; enum func_type which; unsigned int cache; /* region was allocated as part of a cache pool */ - size_t len; unsigned int fence; unsigned char data[0]; } *regions[SOME_PRIME]; @@ -462,6 +475,11 @@ static struct ast_cli_entry cli_memory[] = { void __ast_mm_init(void) { char filename[PATH_MAX]; + size_t pad = sizeof(struct ast_region) - offsetof(struct ast_region, data); + + if (pad) { + ast_log(LOG_ERROR, "struct ast_region has %d bytes of padding! This must be eliminated for low-fence checking to work properly!\n", (int) pad); + } ast_cli_register_multiple(cli_memory, sizeof(cli_memory) / sizeof(struct ast_cli_entry)); |