bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17591: Offload hook fails to send files


From: Ludovic Courtès
Subject: bug#17591: Offload hook fails to send files
Date: Wed, 28 May 2014 17:13:36 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

address@hidden (Ludovic Courtès) skribis:

> $ guix archive --export $(guix build -d coreutils) > t.nar
> $ while guix archive --import <t.nar ; do : ; done

Slightly reduced test case: after creating t.nar as above, run the code
below in a loop until it stops (with a pre-5895f24 Guix!):

--8<---------------cut here---------------start------------->8---
(use-modules (guix)
             (gnu packages base)
             (rnrs io ports))

(with-store store
  (let* (;; (drv   (package-derivation store coreutils))
         ;; (dump  (call-with-bytevector-output-port
         ;;         (lambda (port)
         ;;           (export-paths store (list (derivation-file-name drv))
         ;;                         port))))
         (dump  (call-with-input-file "t.nar" get-bytevector-all)))
    (unless (pair?
             (pk 'import (import-paths store (open-bytevector-input-port 
dump))))
      (format #t
              "attach GDB to ~a, call GC_default_print_heap_obj_proc,etc.~%"
              (getpid))
      (sleep 1000)
      (exit 1))))
--8<---------------cut here---------------end--------------->8---

Also useful is to modify libguile like this:

diff --git a/libguile/bytevectors.c b/libguile/bytevectors.c
index be8b654..9a8902f 100644
--- a/libguile/bytevectors.c
+++ b/libguile/bytevectors.c
@@ -315,10 +315,14 @@ scm_c_shrink_bytevector (SCM bv, size_t c_new_len)
   SCM_BYTEVECTOR_SET_LENGTH (bv, c_new_len);
 
   if (SCM_BYTEVECTOR_CONTIGUOUS_P (bv))
+    {
+      fprintf (stderr, "%s %zi -> %zi\n", __func__, c_len, c_new_len);
       new_bv = PTR2SCM (scm_gc_realloc (SCM2PTR (bv),
                                        c_len + SCM_BYTEVECTOR_HEADER_BYTES,
                                        c_new_len + SCM_BYTEVECTOR_HEADER_BYTES,
                                        SCM_GC_BYTEVECTOR));
+      printf ("new_bv = %p, bv = %p\n", new_bv, bv);
+    }
   else
     {
       signed char *c_bv;
Here I see uninteresting things like:

--8<---------------cut here---------------start------------->8---
scm_c_shrink_bytevector 32768 -> 6960
new_bv = 0x1e96000, bv = 0x1e9a000
importing path `/gnu/store/5nhsz368f88bbgkjjwzz5k24nnnrk544-coreutils-8.22.drv'

;;; (import ("/gnu/store/5nhsz368f88bbgkjjwzz5k24nnnrk544-coreutils-8.22.drv"))
scm_c_shrink_bytevector 32768 -> 6960
new_bv = 0x1efb000, bv = 0x1eff000

;;; (import ())
attach GDB to 10124
--8<---------------cut here---------------end--------------->8---

Then I can call GC_default_print_heap_obj_proc(0x1efb000) from GDB,
which displays:

--8<---------------cut here---------------start------------->8---
object at 0x1efb000 of appr. 6992 bytes (atomic)
--8<---------------cut here---------------end--------------->8---

IOW, everything looks alright, except that the contents of new_bv really
are corrupt.

Ludo’.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]