[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