[uClibc]Re: fressh-0.3 works on mipsel. Thanks!

Matthew Bloch matthew at bytemark.co.uk
Mon Sep 30 11:27:31 UTC 2002


On Monday 30 September 2002 11:58, Matthew Bloch wrote:
> On Monday 30 September 2002 10:44, Matthew Bloch wrote:
> > On Monday 30 September 2002 06:02, Joseph Chiu wrote:
> > > Hi Matthew,
> > >
> > > Wow - Thanks for that fressh patch.  I was able to use it to
> > > cross-compile fressh for mipsel, something that's been bugging me for
> > > quite a while.
> > >
> > > I just had a few more bumps -- my mipsel-uclibc-gcc (built against
> > > gcc-3.0.4) complained about uninitialized variables and multiline
> > > literals; and uclibc (perhaps only on MIPS?) returned NULL's for
> > > malloc(0).
> > >
> > > I fudged the malloc(0) problem by always allocating an extra byte.
> >
> > Hmmm, yes, I noticed that there were malloc(0)s in the ltrace which
> > almost corresponded with the crash I saw, but uClibc's malloc seems fine
> > with allocating and freeing a zero-size block, at least in a quick test
> > program I tried.  I'll try the sshd under the debugger to see exactly
> > what's wrong...
>
> Well it looks like something to do with zero-sized buffers, and I suspect a
> bug in the FreSSH code being shown up by uClibc not "emulating" some
> behaviour of glibc.

Here we go, try compiling this program under uClibc and glibc:

------------------------------- realloc0.c ---------------------------------
#include <stdlib.h>

int main(int argc, char **argv)
{
    void *ptr = NULL;
    ptr = realloc(ptr, 0);
    printf("pointer = %p\n", ptr);
    return 0;
}
----------------------------------------------------------------------------

glibc prints a valid pointer, uClibc prints (nil).  I suggest that this is a 
uClibc bug because glibc's behaviour is explicit in that "If you pass a null 
pointer for PTR, `realloc' behaves just like `malloc (NEWSIZE)'".  uClibc 
will happily return a valid pointer for malloc(0) but realloc(NULL, 0) does 
not behave the same way.

Also I only found this bug in uClibc after fixing a bug in the fressh buffer 
allocation routine which relied on an uninitialised pointer being zero; 
updated complete patch attached.

-- 
Matthew Bloch         Bytemark Computer Consulting Limited
                                http://www.bytemark.co.uk/
                                  tel. +44 (0) 8707 455026
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fressh-linux.patch.gz
Type: application/x-gzip
Size: 2991 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20020930/439af17d/attachment.bin 


More information about the uClibc mailing list