1. 10 7月, 2008 4 次提交
  2. 09 7月, 2008 10 次提交
  3. 08 7月, 2008 1 次提交
  4. 07 7月, 2008 5 次提交
  5. 02 7月, 2008 1 次提交
  6. 30 6月, 2008 1 次提交
  7. 27 6月, 2008 5 次提交
  8. 26 6月, 2008 2 次提交
  9. 25 6月, 2008 4 次提交
  10. 24 6月, 2008 2 次提交
  11. 19 6月, 2008 5 次提交
    • D
      fix a couple of List functions for max = 0 issues · 1ec7cccb
      Daniel Veillard 提交于
      * src/xen_internal.c src/xend_internal.c: fix a couple of issues
        for List functions where max given is 0
      Daniel
      1ec7cccb
    • J
      virsh fails to read files larger than BUFSIZ bytes · e09fab39
      Jim Meyering 提交于
      * src/util.c (fread_file_lim): Use VIR_REALLOC_N, not VIR_ALLOC_N.
      Bug introduced in 895d0fdf.
      * tests/Makefile.am (test_scripts): Add read-bufsiz.
      * tests/read-bufsiz: New test for the above.
      e09fab39
    • C
    • C
      For 0.4.3, danpb's new memory management scheme went into libvirt. This is · 0aa6eedd
      Chris Lalancette 提交于
      fine, except that is subtly alters the semantics of malloc(), calloc(), and
      realloc().  In particular, if you say:
      
      foo = malloc(0);
      
      glibc will happily return a non-NULL pointer to you.  However, with the new
      memory management stuff, if you say:
      
      foo = VIR_ALLOC(0);
      
      you will actually get a NULL pointer back.  Personally, I think this is a
      dangerous deviation from malloc() semantics that everyone is used to, and is
      indeed causing problems with the remote driver.  The short of it is that the
      remote driver allocates memory on behalf of the remote side using VIR_ALLOC_N,
      and this call is returning NULL so that the NULL checks elsewhere in the code
      fire and return failure.
      
      The attached patch fixes this situation by removing the 0 checks from the memory
      allocation paths, and just lets them fall through to the normal malloc(),
      calloc(), or realloc() routines, restoring old semantics.
      Signed-off-by: NChris Lalancette <clalance@redhat.com>
      0aa6eedd
    • C
      When doing the conversion to danpb's new memory API, a small bug was · a24b1d9e
      Chris Lalancette 提交于
      introduced into the qemudNetworkIfaceConnect() function.  In particular, there
      is a call:
      
          if (VIR_ALLOC_N(vm->tapfds, vm->ntapfds+2) < 0)
              goto no_memory;
      
      However, the tapfds structure is used to track *all* of the tap fds, and is
      called once for each network that is being attached to the domain.  VIR_ALLOC_N
      maps to calloc().  So the first network would work just fine, but if you had
      more than one network, subsequent calls to this function would blow away the
      stored fd's that were already there and fill them all in with zeros.  This
      causes multiple problems, from the qemu domains not starting properly to
      improper cleanup on shutdown.  The attached patch just changes the VIR_ALLOC_N()
      to a VIR_REALLOC_N(), and everything is happy again.
      Signed-off-by: NChris Lalancette <clalance@redhat.com>
      a24b1d9e