[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