apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] fix alignment on shared memory
Date Fri, 01 Mar 2002 17:34:49 GMT
Aaron Bannert <aaron@clove.org> writes:

> I've still got sleep in my eyes, so I might not be seeing this correctly
> yet, but isn't the problem not that the segment itself is misaligned,
> but that the structure that is being placed over that segment not
> properly padded to account for alignment?
> 
> This looks like the problem to me:
> 
> AP_DECLARE(int) ap_calc_scoreboard_size(void)
> {
>     ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit);
>     ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit);
>     scoreboard_size = sizeof(global_score);
>     scoreboard_size += sizeof(process_score) * server_limit;
>     scoreboard_size += sizeof(worker_score) * server_limit * thread_limit;
>     return scoreboard_size;
> }

I'll punt for the moment on whether or not that code is bad.  The
shared memory code definitely needs to be fixed.  Look at this simple
test of alignment:

#include <stddef.h>
#include <stdio.h>

int main(void)
{
    struct s1 {
        char a;
        char b;
    } s1;
    struct s2 {
        char a;
        int b;
    } s2;
    struct s3 {
        char a;
        long long b;
    } *s3;
    struct s4 {
        char a;
        double b;
    } s4;

    printf("%d %d %d %d\n",
           offsetof(struct s1,b),
           offsetof(struct s2,b),
           offsetof(struct s3,b),
           offsetof(struct s4,b));

    s3 = (struct s3 *)((char *)malloc(100) + 4);
    printf("%p\n",s3);
    s3->a = 'A';
    s3->b = 10241024;
    return 0;
}

On my sparc machine it prints
1 4 8 8
for the offsets of the variables of different types.  Note that gcc
places long long and double on 64-bit boundaries.

It then dies with SIGBUS when I trick it into trying to store a
64-bit quantity into storage which s 32-bit aligned but not 64-bit
aligned.

Back to the code above that you posted:

I think that it too needs to take into account alignment.  It would
need to round the size of each structure up to 64-bit alignmet before
multiplying to ensure that objects of any type can live in that
storage.  This currently isn't causing problems because the size of
each structure is consistent with 64-bit alignment (208 bytes for
worker_score, 24 bytes for global_score, 16 bytes for process_score),
at least in a 32-bit build for Sparc.

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message