[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’.