Re: Antwort: Re: Antwort: Re: -EFAULT during freeing a pointer to a structure

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

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

On Fri, 2004-10-08 14:27:11 +0200, p.boehm@d-trust.net <p.boehm@d-trust.net>
wrote in message <OF9FBCFEF1.D1EE727C-ONC1256F27.0043E708@bln.d-trust.de>:
> 
> sorry, but it isn't a problem of loop. check this while running the prog...

It *is* a problem of the loop.
> test one:
> 
>      #define MAXNUM 7
>      compile it and run ...
>      you'll see while freeing ptr->next[0] an -EFAULT occours.

Right, because:

struct abc {                                                                              
     struct xy *next[MAXNUM];                                                             
};                                                                                        

You malloc one of these struct abc. It's size depends on MAXNUM. You're
not allowed to access the "next" array with any index outside of
[0 .. MAXNUM-1]. If you do, unpredictable results happen (as you see:-)

> test two:
> 
>      #define MAXMUM 8
>      compile it and run ...
>      you'll see freeing ptr->next[0] works fine.
> 
> my question: why it is so.

Because by writing to the ->next[8] element, which is outside of what
you had allocated before, you overwrite glibc's internal housekeeping
data.

Glibc's internal malloc functions are written for correctness and speed.
They don't tolerate being abused by writing data to memory outside your
allocated memory.

In your example above, using MAXNUM=7, I guess glibc internally
allocates 32 bytes (28 to be used for struct abc) and the last four
bytes for glibc's own bookkeeping. By writing to ->next[8] (which is
syntactically correct, but semantically not allowed, because you
declared the array to be one element shorter than this:-) ,  you
overwrite data which is internal to glibc. Some time later (at free()
time), this internal data (you previously overwrote because the loops
were semantically broken) gets used and is wrong (because you altered
it). It's okay to crash then.

In the case of MAXNUM=8, glibc probably allocates a 2nd chunk of 32
bytes to store it's internal data. ...and because it's internal data is
probably stored in it's last 4 bytes, you don't overwrite it, because
you only overwrite the first 4 byte of this extra block of memory.

To keep the long story short, your program wrote to memory it's not
permitted to write to and subsequently crashes. That's totally okay and
expected. Just fix those two loops to stay within the range allowed for
the index.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]