[uClinux-dev] do_global_dtors problem

Matt Waddel mattw at lineo.com
Mon Nov 5 11:10:33 EST 2001


Håkan and David,

That fixed the problem.

Thanks,
Matt


Håkan Magnusson wrote:

> Hello!
> Just a fast look in file user/fileutils/cat.c spend a lot of unused ram for the
> readbuf[CAT_BUF_SIZE].
> Skip the variable cat_read_size & reduce the size of CAT_BUF_SIZE]
> Change as below:
>
>       diff cat*
>      14c14
>      < #define CAT_BUF_SIZE 4096
>      ---
>      > #define CAT_BUF_SIZE 10
>      16d15
>      < int cat_read_size = 1;
>      26c25
>      <       while ((nred=read(fd,readbuf,cat_read_size)) > 0) {
>      ---
>      >       while ((nred = read(fd, readbuf, sizeof(readbuf))) > 0) {
>
> (:-}= Håkan Magnusson
>
> David McCullough wrote:
>
> > Jivin Matt Waddel lays it down ...
> > > Hi,
> > >
> > > I have been getting the following results on an M5272C3
> > > system when I use the "cat" command from the Fileutils
> > > userland package.
> > >
> > > # cat /etc/inittab
> > > inet:unknown:/bin/inetd
> > > boa:unknown:/bin/boa
> > > Illegal instruction
> > > #
> > >
> > > Using gdbserver I have traced it to the do_global_dtors
> > > routine.  It loads in a very large value then tries to jump
> > > there and this causes cat crash and return to a shell
> > > prompt.  (Sometimes cat will return a SIGSEGV.)
> > >
> > > Since everything seems to run fine after that and
> > > the busybox cat functions properly, I am wondering
> > > if there is a subtle problem with the toolchains.
> > >
> > > Has anyone else seen this behavior?  Isn't do_global_dtors
> > > a c++ function?  Any enlightenment on the constructor/
> > > destructor functions would be appreciated.
> >
> > It is unlikely that the problem is with do_global_dtors.   What happens
> > is in the later version of gcc (ie 2.95) main calls __main which processes
> > do_global_[cd]tors lists.  So you get them with 'C' as well.  Actually,  I
> > think that atexit is processed this way,  but I may be wrong.
> >
> > The fact that the program has run to completion and then crashed would make
> > me look at the stack size and see if it could be overflowing into the top
> > of the BSS/data sections.
> >
> > Actually,  one look at the code shows a 4096 byte buffer,  and the Makefile
> > doesn't specify a stack size,  so you get the default 4096 stack.  Not a
> > very good combo ;-)  Make the char array a static:
> >
> >         diff -r1.1 cat.c
> >         24c24
> >         <       char readbuf[CAT_BUF_SIZE];
> >         ---
> >         >       static char readbuf[CAT_BUF_SIZE];
> >
> > and you should be on your way ;-)
> >
> > Cheers,
> > Davidm
> >
> > --
> > David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
> > davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
> > This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
>
> This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list