[bug #29463] Translators output garbage when started with settrans -P and stopped by gdb

[Carl Fredrik Hammar]

URL:
  <http://savannah.gnu.org/bugs/?29463>

                 Summary: Translators output garbage when started with
settrans -P and stopped by gdb
                 Project: The GNU Hurd
            Submitted by: hammy
            Submitted on: Wed 07 Apr 2010 08:54:08 PM CEST
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Reproducibility: None
              Size (loc): None
         Planned Release: None
                  Effort: 0.00
Wiki-like text discussion box: 

    _______________________________________________________

Details:

Hi,

Translators sometimes output garbage to terminal when started with
`settrans -P` and has a gdb session attached which has the translator
stopped while exiting from settrans.  Like so:

  [1] $ settrans -acP /tmp/foo /hurd/hello
      Translator pid: 123
      Pausing...

  [2] $ gdb /hurd/hello 123
  [2] (gdb)

  [1] <enter>
      $

  [2] (gdb) continue

  [1] /hurd/hello: trivfs_startup: (ipc/send) invalid destination
porttrivfs_startup<garbage...>

  [2] Program received signal EXC_BAD_ACCESS, Could not access memory.
      0x010ebe92 in _IO_default_xsputn (f=0x11e1460, data=0x124d749,
n=4294967283)
         at genops.c:485 in genops.c

The error message is expected because settrans exits before /hurd/hello
gets the reply to fsys_startup, but the garbage is not.  gdb provides
the following backtrace:

  [2] (gdb) bt
      #0  0x010ebe92 in _IO_default_xsputn (f=0x11e1460, data=0x124d749, 
          n=4294967283) at genops.c:485
      #1  0x010e9a68 in _IO_new_file_xsputn (f=0x11e1460, data=0x124d748,
n=1)
          at fileops.c:1379
      #2  0x010c79a0 in buffered_vfprintf (s=0x11e1460, 
          format=<value optimized out>, args=<value optimized out>)
          at vfprintf.c:2262
      #3  0x010c2e13 in _IO_vfprintf_internal (s=0x11e1460, 
          format=0xffffff01 <Address 0xffffff01 out of bounds>, 
          ap=0xffffffff <Address 0xffffffff out of bounds>) at
vfprintf.c:1306
      #4  0x010df7be in __fxprintf (fp=0x11e1460, fmt=0x11c7cf4 "\n")
          at fxprintf.c:56
      #5  0x0116f094 in error_tail (status=<value optimized out>, 
          errnum=<value optimized out>, message=0x804927c "trivfs_startup", 
          args=0x124fe1c "") at error.c:210
      #6  0x0116f2a8 in __error (status=3, errnum=268435459, 
          message=0x804927c "trivfs_startup") at error.c:253
      #7  0x08048f45 in error (argc=Cannot access memory at address 0x25
      ) at /usr/include/bits/error.h:41
      #8  main (argc=Cannot access memory at address 0x25
      ) at /var/tmp/hurd-20090404/./trans/hello.c:285

This suggests to me that the memory of /hurd/hello has been garbled,
which somehow causes printf to print out a good part of the memory image.
My guess is that gdb is doing the garbling, but I don't know how.

I have tested this with gdb versions 7.0.1-2 and 7.1-2 from Debian,
and with the following translators /hurd/hello and /hurd/null,
but could not reproduce with /hurd/ext2fs so the bug may be in libtrivfs.

Regards,
  Fredrik





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29463>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/