LD_DEBUG crashes applications

[Diego Nieto Cid]

Hi

  Summary: here is a little report about LD_DEBUG issues
    I've mentioned a few weeks ago in the dlerror thread.
    There seems to be some corruption related to ld.so
    printing to stderr, although I couldn't yet find
    where. 

I've been doing some test to catch a bug present in my system, and
the netinst rescue shell, where setting the LD_DEBUG makes the
application being run under such environment crash.

The symptoms vary depending on what value the environment variable
takes.

When setting it to 'bindings' or 'symbols', the loader produces
some output but is finally killed while '_hurd_intr_rpc_mach_msg'
symbol is being loaded. The shell prints 'Killed' and '$?' is 137.
GDB says:

  Program received signal ?, Unknown signal.
  0x0001052b in _dl_start_profile () at dl-profile.c:242
  242             log_hashfraction = 4;
  (gdb) disassemble $eip,+8
  Dump of assembler code from 0x1052b to 0x10533:
  => 0x0001052b <_dl_start_profile+235>:  mov    %eax,-0x24c(%ebp)
     0x00010531 <_dl_start_profile+241>:  lea    -0x224(%ebp),%eax

However, when it's set to 'statistics', the executed program runs
to completion (for instance, 'ls' produces the expected output) but
a segmentation fault is triggered at the following location:

  Program received signal SIGSEGV, Segmentation fault.
  0x00017812 in __strerror_r (errnum=16959932,
      buf=0x1 <error: Cannot access memory at address 0x1>,
      buflen=73) at dl-minimal.c:189
  189           msg = memcpy (msg - (sizeof ("Error ") - 1), "Error ",
  (gdb) disassemble $eip,+8
  Dump of assembler code from 0x17812 to 0x1781a:
  => 0x00017812 <__strerror_r+194>:       pushl  (%eax,%edi,4)
     0x00017815 <__strerror_r+197>:       call   0x1aff0 <__mutex_lock_solid>

Note that I've run the program in gdb through the loader as
suggested by glibc documentation:

    $ gdb <path to ld.so>
    (gdb) set exec-wrapper env LD_DEBUG=statistics
    (gdb) run /bin/ls

The first looks like a stack corruption and in the second one, buf
is bogus. I'm not sure whether both failures are related.

What I could actually find out is that the crashes are produced by
some bad behaviour when printing from ld.so. If I disable printing
of debugging messages, but leave everything else intact, as in the
following patch:


Index: glibc-2.22/sysdeps/mach/hurd/dl-sysdep.c
===================================================================
--- glibc-2.22.orig/sysdeps/mach/hurd/dl-sysdep.c
+++ glibc-2.22/sysdeps/mach/hurd/dl-sysdep.c
@@ -420,16 +420,16 @@ __writev (int fd, const struct iovec *io
     {
       char buf[total], *bufp = buf;
       error_t err;
-      mach_msg_type_number_t nwrote;
+      mach_msg_type_number_t nwrote = total;
 
       for (i = 0; i < niov; ++i)
        bufp = (memcpy (bufp, iov[i].iov_base, iov[i].iov_len)
                + iov[i].iov_len);
-
+/*
       err = __io_write (_hurd_init_dtable[fd], buf, total, -1, &nwrote);
       if (err)
        return __hurd_fail (err);
-
+*/
       return nwrote;
     }
   return 0;


then the loader/program no longer crashes. 

Thanks,
Diego