l...@gnu.org (Ludovic Courtès) skribis: > ==8395== Syscall param write(buf) points to uninitialised byte(s) > ==8395== at 0x53E4A8D: ??? (in > /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libpthread-2.25.so) > ==8395== by 0xACAF44D: _gdbm_full_write (in > /gnu/store/kg8ffb14msfnc9aivxj6djrl51g9b3zz-gdbm-1.13/lib/libgdbm.so.4.0.0) > ==8395== by 0xACAC6AD: gdbm_fd_open (in > /gnu/store/kg8ffb14msfnc9aivxj6djrl51g9b3zz-gdbm-1.13/lib/libgdbm.so.4.0.0)
This is almost certainly an uninitialized malloc’d area that goes straight to disk as can be seen by running the script I gave before with ‘MALLOC_PERTURB_’ set: --8<---------------cut here---------------start------------->8--- ludo@ribbon ~/src/guix$ MALLOC_PERTURB_=22 ./pre-inst-env guile t.scm ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") C-c C-c ludo@ribbon ~/src/guix$ MALLOC_PERTURB_=44 ./pre-inst-env guile t.scm ;;; (33554432 "03kl992ypwxxp4cplbhz05b04ihjh96d3pldwgz7qaj4ls0qssr3") ;;; (33554432 "03kl992ypwxxp4cplbhz05b04ihjh96d3pldwgz7qaj4ls0qssr3") ;;; (33554432 "03kl992ypwxxp4cplbhz05b04ihjh96d3pldwgz7qaj4ls0qssr3") ;;; (33554432 "03kl992ypwxxp4cplbhz05b04ihjh96d3pldwgz7qaj4ls0qssr3") C-c C-c ludo@ribbon ~/src/guix$ MALLOC_PERTURB_=22 ./pre-inst-env guile t.scm ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") ;;; (33554432 "18rzgjskkgllwfkdyx7gbcc3z6aqsqm9lm6dzs9yrw9z7ppqx0na") --8<---------------cut here---------------end--------------->8--- So for now, until gdbm is fixed, we can always work around the issue by setting MALLOC_PERTURB_. How does that sound? Ludo’.
