[Savannah-hackers] Re: Autoconf @ Red Hat

[Jason Molenda]

On Fri, Mar 22, 2002 at 12:27:11PM +0100, Akim Demaille wrote:
> >>>>> "Jason" == Jason Molenda <address@hidden> writes:

> 
> I didn't know you were back to sources^Hware!  :)

I'm not really involved with sourceware any longer - I just kibitz
from the side and play around with the system occasionally.
Chris Faylor has been doing all the real work for a year or two now.
These last few months I've mostly amused myself with silly little
things like my makethumbs.sh project.

Incidentally, as long as I'm here being utterly off-topic, has
everyone seen Valgrind?

        http://www.muraroa.demon.co.uk/

It's Julian Seward's (creator of bzip2, worked on a free Haskell
compiler for many years) latest project.  It simulates your x86
Linux program and tracks every bit of memory as your program runs.
It tracks which bits of each byte of memory have valid, initialized
values (and only warns when you try to use the value of an
uninitialized bit, so copying them around is fine) and it tracks
which bytes of memory are validly accessible to your program.  It
catches these sorts of mistakes:

     * Use of uninitialised memory
     * Reading/writing memory after it has been free'd
     * Reading/writing off the end of malloc'd blocks
     * Reading/writing inappropriate areas on the stack
     * Memory leaks -- where pointers to malloc'd blocks are lost forever
     * Passing of uninitialised and/or unaddressible memory to system calls
     * Mismatched use of malloc/new/new [] vs free/delete/delete []

It doesn't require any modification of your program; it uses the
dynamic loader to gain control before your program does anything.
It is amazing.  You get a 25-50 times slowdown in execution speed,
but it's a minor detail.

Here's me running it on gdb before I went to sleep last night.  It
has an option to run gdb on the inferior process when it detects
a problem.

  address@hidden valgrind-20020320]$ ./valgrind --gdb-attach=yes 
~/sware/gdb/i/bin/gdb
  ==1638== valgrind-20020320, a memory error detector for x86 GNU/Linux.
  ==1638== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
  ==1638== For more details, rerun with: -v
  ==1638==
  GNU gdb 2002-03-22-cvs
  This GDB was configured as "i686-pc-linux-gnu".
  (gdb) set prompt (top-valgrind-gdb)
  (top-valgrind-gdb) file ~/sware/gdb/i/bin/gdb
  Reading symbols from ~/sware/gdb/i/bin/gdb...done.
  (top-valgrind-gdb) info func main
  ==1638== Invalid read of size 4
  ==1638==    at 0x816513F: finish_block (../../src/gdb/buildsym.c:278)
  ==1638==    by 0x8127988: process_one_symbol (../../src/gdb/dbxread.c:2758)
  ==1638==    by 0x8127703: read_ofile_symtab (../../src/gdb/dbxread.c:2602)
  ==1638==    by 0x81271AB: dbx_psymtab_to_symtab_1 
(../../src/gdb/dbxread.c:2430)
  ==1638==    Address 0x4319BEAC is 0 bytes after a block of size 4072 alloc'd
  ==1638==    at 0x40065842: malloc (vg_clientmalloc.c:618)
  ==1638==    by 0x80F1A5D: mmalloc (../../src/gdb/utils.c:892)
  ==1638==    by 0x80F1B4A: xmmalloc (../../src/gdb/utils.c:1011)
  ==1638==    by 0x80F1C73: xmalloc (../../src/gdb/utils.c:1083)
  ==1638==
  ==1638== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y

I've told it to start gdb on the process when it finds a problem.
The bottommost four frames are valgrind internals, but above that
it's pure gdb.

  starting GDB with cmd: /usr/bin/gdb -nw /proc/1638/exe 1638
  GNU gdb Red Hat Linux (5.1-1)
  This GDB was configured as "i386-redhat-linux"...
  /usr/local/src/valgrind/valgrind-20020320/1638: No such file or directory.
  Attaching to program: /proc/1638/exe, process 1638
  Reading symbols from ./valgrind.so...done.
  Loaded symbols for ./valgrind.so
  Reading symbols from /usr/lib/libncurses.so.5...done.
  Loaded symbols for /usr/lib/libncurses.so.5
  Reading symbols from /lib/i686/libm.so.6...done.
  Loaded symbols for /lib/i686/libm.so.6
  Reading symbols from /lib/libdl.so.2...done.
  Loaded symbols for /lib/libdl.so.2
  Reading symbols from /lib/i686/libc.so.6...done.
  Loaded symbols for /lib/i686/libc.so.6
  Reading symbols from /lib/ld-linux.so.2...done.
  Loaded symbols for /lib/ld-linux.so.2
  Reading symbols from /lib/libthread_db.so.1...done.
  Loaded symbols for /lib/libthread_db.so.1
  0x403eaca9 in __wait4 () from /lib/i686/libc.so.6
  (gdb) bt
  #0  0x403eaca9 in __wait4 () from /lib/i686/libc.so.6
  #1  0x404666b4 in __DTOR_END__ () from /lib/i686/libc.so.6
  #2  0x4037f782 in __libc_system (
      line=0xbfffdb68 "/usr/bin/gdb -nw /proc/1638/exe 1638")
      at ../sysdeps/posix/system.c:136
  #3  0x4005b377 in vgPlain_start_GDB_whilst_on_client_stack () at 
vg_main.c:1298
  #4  0x0816513f in finish_block (symbol=0x4319bddc, listhead=0x828936c,
      old_blocks=0x4319bdd4, start=134783564, end=134783594, 
objfile=0x4258e9ac)      at ../../src/gdb/buildsym.c:278
  #5  0x08127988 in process_one_symbol (type=36, desc=0, valu=30,
      name=0x42a1502c "", section_offsets=0x42593d40, objfile=0x4258e9ac)
      at ../../src/gdb/dbxread.c:2758
  #6  0x08127703 in read_ofile_symtab (pst=0x42cf6af8)
      at ../../src/gdb/dbxread.c:2602
  #7  0x081271ab in dbx_psymtab_to_symtab_1 (pst=0x42cf6af8)
      at ../../src/gdb/dbxread.c:2430
  #8  0x08127124 in dbx_psymtab_to_symtab_1 (pst=0x42cfde5c)
      at ../../src/gdb/dbxread.c:2416
  #9  0x08127124 in dbx_psymtab_to_symtab_1 (pst=0x42cfe74c)
      at ../../src/gdb/dbxread.c:2416
  #10 0x08127124 in dbx_psymtab_to_symtab_1 (pst=0x42ee7bd8)
      at ../../src/gdb/dbxread.c:2416
  #11 0x08127281 in dbx_psymtab_to_symtab (pst=0x42ee7bd8)
      at ../../src/gdb/dbxread.c:2471
  #12 0x08093924 in psymtab_to_symtab (pst=0x42ee7bd8)
      at ../../src/gdb/symfile.c:372
  #13 0x0809080b in search_symbols (regexp=0x4252e096 "main",
      kind=FUNCTIONS_NAMESPACE, nfiles=0, files=0x0, matches=0xbfffdf04)
      at ../../src/gdb/symtab.c:2612
  #14 0x08091256 in symtab_symbol_info (regexp=0x4252e096 "main",
      kind=FUNCTIONS_NAMESPACE, from_tty=1) at ../../src/gdb/symtab.c:2866
  #15 0x0809138e in functions_info (regexp=0x4252e096 "main", from_tty=1)
      at ../../src/gdb/symtab.c:2910
  [...]

  (gdb) frame 4
  #4  0x0816513f in finish_block (symbol=0x43195f74, listhead=0x828936c, 
      old_blocks=0x43195f6c, start=134783564, end=134783594, objfile=0x42586dd0)
      at ../../src/gdb/buildsym.c:278
  278             ALL_BLOCK_SYMBOLS (block, i, sym)
  (gdb) list
  273             /* No parameter type information is recorded with the
  274                function's type.  Set that from the type of the
  275                parameter symbols. */
  276             int nparams = 0, iparams;
  277             struct symbol *sym;
  278             ALL_BLOCK_SYMBOLS (block, i, sym)
  279               {
  280                 switch (SYMBOL_CLASS (sym))
  281                   {
  282                   case LOC_ARG:
  (gdb) p i
  $11 = 2
  (gdb) p *block
  $13 = {startaddr = 134783564, endaddr = 134783594, function = 0x4319bddc, 
    superblock = 0x0, gcc_compile_flag = 2 '\002', nsyms = 2, sym = 
{0x4319be1c}}

(as you could tell from the original valgrind error message, it
appears that ALL_BLOCK_SYMBOLS is iterating one too many times.
I want to play with valgrind some more so I'll look into it this
weekend.)

Simulating the program (including glibc, X, etc., and using
syscall-descriptors to describe what will happen to system calls)
allows for a lot of checking that I've never seen anyone do before.
It's a great little program.

Jason