[uClibc]strcmp

David Meggy dmeggy at techsol.ca
Thu Nov 14 23:11:32 UTC 2002


I found what started the problem in uClibc.  It was a change between
Sept.30 and Oct.1 in CVS

I kept going back in the logs until it worked again and I found that
this was the patch that broke uClibc:
http://www.uclibc.org/cgi-bin/cvsweb/uClibc/libc/sysdeps/linux/arm/crt0.S.diff?r1=1.13&r2=1.14
http://www.uclibc.org/cgi-bin/cvsweb/uClibc/libc/misc/internals/__uClibc_main.c.diff?r1=1.25&r2=1.26



David


On Wed, 2002-11-13 at 18:00, Erik Andersen wrote:
> On Wed Nov 13, 2002 at 01:23:37PM -0800, David Meggy wrote:
> > I'm having problems when s1 = NULL.  The function never checks for this
> > case.  If it isn't the C library's responsibility to check then there is
> > a bug in Busybox.  I run into this problem when init_main calls strcmp. 
> > Shown here:
> > 
> > extern int init_main(int argc, char **argv)
> > {
> >         struct init_action *a;
> >         pid_t wpid;
> >         int status;
> > 
> >         if (argc > 1 && !strcmp(argv[1], "-q")) {
> >                 /* don't assume init's pid == 1 */
> >                 long *pid = find_pid_by_name("init");
> >                 if (!pid || *pid<=0) {
> > 
> > 
> > Now if argc is > 1 then argv[1] should be valid, unless busybox passed
> > incorrect values into this function.
> 
> Sounds to me like your stack is hosed up.  What architecture and
> kernel version are you using?  If have some tools I use for
> checking your stack is sane, but if you are using a know hosed up
> kernel we can save the bother,
> 
>  -Erik
> 
> --
> Erik B. Andersen             http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
-- 
~~~~~~~~~~~~~~~~~~~~~~~~
     David Meggy
     Engineering

Technical Solutions Inc.
Unit #1 7157 Honeyman St
Delta BC Canada, V4G 1E2
     www.techsol.ca

eMail: dmeggy at techsol.ca
Tel: 604 946 TECH (8324)
Fax: 604 946 6445
~~~~~~~~~~~~~~~~~~~~~~~~




More information about the uClibc mailing list