[Aboriginal] Merry christmas, I have found two bugs

Rob Landley rob at landley.net
Wed Dec 26 22:37:46 PST 2012


On 12/26/2012 05:44:19 PM, Bjørn Forsman wrote:
> On 27 December 2012 00:02, Bjørn Forsman <bjorn.forsman at gmail.com>  
> wrote:
> > On 26 December 2012 23:23, Bjørn Forsman <bjorn.forsman at gmail.com>  
> wrote:
> > [...]
> >> Now when I get toybox rebuilt with debug symbols I can figure out
> >> (from the core file) where the bug is.
> >
> > I built toybox in a ./dev-environment.sh and caused a coredump with
> > "./toybox_unstripped ls". Then I exited and mounted hda.sqf to
> > mnt_rootfs/ and hdb.img to mnt_home/. This my backtrace:
> >
> > bfo at knopfler ~/aboriginal/build/system-image-armv5l $ sudo $(which
> > arm-none-linux-gnueabi-gdb) mnt_home/toybox-0.4.2/toybox_unstripped
> > mnt_home/toybox-0.4.2/core
> > GNU gdb (Sourcery CodeBench Lite 2012.03-57) 7.2.50.20100908-cvs
> > Copyright (C) 2010 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later  
> <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show  
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "--host=i686-pc-linux-gnu
> > --target=arm-none-linux-gnueabi".
> > For bug reporting instructions, please see:
> > <https://support.codesourcery.com/GNUToolchain/>...
> > Reading symbols from
> >  
> /home/bfo/aboriginal/build/system-image-armv5l/mnt_home/toybox-0.4.2/toybox_unstripped...done.
> >
> > warning: core file may not match specified executable file.
> > [New LWP 1886]
> >
> > warning: Could not load shared library symbols for 6 libraries, e.g.
> > /lib/libutil.so.0.
> > Use the "info sharedlibrary" command to see the complete listing.
> > Do you need "set solib-search-path" or "set sysroot"?
> >
> > warning: Unable to find dynamic linker.
> > GDB will be unable to debug shared library initializers
> > and track explicitly loaded dynamic code.
> > Core was generated by `./toybox_unstripped ls'.
> > Program terminated with signal 8, Arithmetic exception.
> > #0  0xb6edbd34 in ?? ()
> > (gdb) set sysroot mnt_rootfs/
> > Reading symbols from mnt_rootfs/lib/libutil.so.0...(no debugging
> > symbols found)...done.
> > Loaded symbols for mnt_rootfs/lib/libutil.so.0
> > Reading symbols from mnt_rootfs/lib/libcrypt.so.0...(no debugging
> > symbols found)...done.
> > Loaded symbols for mnt_rootfs/lib/libcrypt.so.0
> > Reading symbols from mnt_rootfs/lib/libm.so.0...(no debugging  
> symbols
> > found)...done.
> > Loaded symbols for mnt_rootfs/lib/libm.so.0
> > Reading symbols from mnt_rootfs/lib/libgcc_s.so.1...(no debugging
> > symbols found)...done.
> > Loaded symbols for mnt_rootfs/lib/libgcc_s.so.1
> > Reading symbols from mnt_rootfs/lib/libc.so.0...(no debugging  
> symbols
> > found)...done.
> > Loaded symbols for mnt_rootfs/lib/libc.so.0
> > Reading symbols from mnt_rootfs/lib/ld-uClibc.so.0...(no debugging
> > symbols found)...done.
> > Loaded symbols for mnt_rootfs/lib/ld-uClibc.so.0
> > (gdb) bt
> > #0  0xb6edbd34 in raise () from mnt_rootfs/lib/libc.so.0
> > #1  0x00028d84 in __div0 () at
> >  
> /home/bfo/aboriginal/build/temp-armv5l/gcc-core/gcc/config/arm/lib1funcs.asm:1000
> > #2  0x000280c8 in __udivsi3 () at
> >  
> /home/bfo/aboriginal/build/temp-armv5l/gcc-core/gcc/config/arm/lib1funcs.asm:754
> > #3  0x0001a1d0 in next_column (ul=0, dtlen=16, columns=0,
> > xpos=0xbee639d0) at toys/posix/ls.c:186
> > #4  0x0001a8b8 in listfiles (dirfd=3, indir=0x6b5580) at  
> toys/posix/ls.c:308
> > #5  0x0001a420 in listfiles (dirfd=-100, indir=0x6b54f8) at  
> toys/posix/ls.c:228
> > #6  0x0001b3a0 in ls_main () at toys/posix/ls.c:455
> > #7  0x0000b224 in toy_exec (argv=0xbee63e48) at main.c:104
> > #8  0x0000b2b0 in toybox_main () at main.c:119
> > #9  0x0000b224 in toy_exec (argv=0xbee63e44) at main.c:104
> > #10 0x0000b2b0 in toybox_main () at main.c:119
> > #11 0x0000b4a4 in main (argc=2, argv=0xbee63e44) at main.c:161
> > (gdb)
> >
> > Let me know if you see something in there. I'll probably take a  
> deeper
> > look at this tomorrow.
> 
> ...I couldn't wait.
> 
> (gdb) up
> #3  0x0001a1d0 in next_column (ul=0, dtlen=16, columns=0,
> xpos=0xbee639d0) at toys/posix/ls.c:186
> 186	  height = (dtlen+columns-1)/columns;
> 
> So this is where the SIGFPE/division-by-zero error comes from:  
> columns=0.
> 
> And columns=0 comes from listfiles():
> 
> (gdb) up
> #4  0x0001a8b8 in listfiles (dirfd=3, indir=0x6b5580) at  
> toys/posix/ls.c:308
> 308	    unsigned long next = next_column(ul, dtlen, columns,  
> &curcol);
> 
> And columns gets its zero value from this line, inside listfiles():
> 
>     if (columns > TT.screen_width/2) columns = TT.screen_width/2;
> 
> On my system (and yours too, apparently), TT.screen_width is zero!  
> (Why?)

Because /dev/console hooks up to a serial device, and serial devices  
don't inherently have a width or height. (There's no attached display  
device, even though it's a console. Consoles do multiple things and  
this hardware only supports some of them, so the rest are stubbed out.  
Unfortunately, they're not stubbed out _consistently_ across different  
drivers...)

I see another part of the problem, which is that this code:

   http://landley.net/hg/toybox/file/017b8fd3c9ac/lib/lib.c#l936

The parts filtering out x=0 or y=0 aren't vetoing zero values from the  
ioctl, they're checking the _pointer_ for zero and not recording it. (I  
wrote that code in 2007, the details are fuzzy.)

> I'm not sure what is the proper fix for this, as I'm not familiar with
> this code. Should next_column() simply ensure that columns>=1 or
> something? Or shouldn't that zero be passed on in the first place? In
> general, I don't like the idea of functions blowing up because they
> receive something "unexpected".

The zero should be detected and we'd have additional fallbacks, such as:

   http://lists.busybox.net/pipermail/busybox/2009-May/069296.html

Which is non-obvious because of:
   http://lists.busybox.net/pipermail/busybox/2008-October/067348.html
   http://lists.busybox.net/pipermail/busybox/2008-October/067418.html

Which is why it's still a todo item. In theory if I get toysh doing  
this right, then it can pass the data along to vi and less and such,  
although if you resize a terminal it would have to re-probe (and since  
it doesn't _know_ it would have to do so, it would have to do so fairly  
frequently). The problem with those is other data the user legitimately  
typed is coming in, potentially before and after the escape probe, so  
you've gotta filter all incoming data and pick out the probe response.  
If you're already parsing cursor keys this is easy.

Since ls isn't doiing any of that, probing would just be awkward so  
toysh should set COLUMNS to a sane value. The problem is, we're not  
using toysh yet because it's still just a stub...

Rob


More information about the Aboriginal mailing list