Guix test failure on tests/store.

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Roel Janssen
Owner
unassigned
Submitted by
Roel Janssen
Severity
normal
R
R
Roel Janssen wrote on 12 Dec 2017 13:12
(address . bug-guix@gnu.org)
87tvwwcfhn.fsf@gnu.org
Dear Guix,

I built Guix on our cluster (from commit 8be84d3), and the test suite
fails for "tests/store".

I attached the build log. The relevant bit is this:

actual-error:
+ (srfi-34
+ #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
result: FAIL

Does this mean I have an inconsistency in the store?

Kind regards,
Roel Janssen
Attachment: test-suite.log
L
L
Ludovic Courtès wrote on 12 Dec 2017 17:06
(name . Roel Janssen)(address . roel@gnu.org)(address . 29676@debbugs.gnu.org)
87shcgorq5.fsf@gnu.org
Hi,

Roel Janssen <roel@gnu.org> skribis:

Toggle quote (7 lines)
> I attached the build log. The relevant bit is this:
>
> actual-error:
> + (srfi-34
> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
> result: FAIL

The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
memory corruption, presumably in the daemon.

I suppose the failure random, isn’t it?

Toggle quote (2 lines)
> Does this mean I have an inconsistency in the store?

No, definitely not. Those tests run on a scratch store, in
/tmp/guix-tests/store.

Ludo’.
R
R
Roel Janssen wrote on 12 Dec 2017 17:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29676@debbugs.gnu.org)
87shcfdh5w.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (14 lines)
> Hi,
>
> Roel Janssen <roel@gnu.org> skribis:
>
>> I attached the build log. The relevant bit is this:
>>
>> actual-error:
>> + (srfi-34
>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>> result: FAIL
>
> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
> memory corruption, presumably in the daemon.

The daemon used in the test, or the daemon used to do the package build?

Toggle quote (3 lines)
>
> I suppose the failure random, isn’t it?

I ran it again, and I've got the same error:

actual-error:
+ (srfi-34
+ #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)

So that's either a very funny coincidence, or it's a structural problem.

Toggle quote (6 lines)
>
>> Does this mean I have an inconsistency in the store?
>
> No, definitely not. Those tests run on a scratch store, in
> /tmp/guix-tests/store.

Ok. That's some good news at least. :)

Do you have any suggestions for how I can debug this problem?

Kind regards,
Roel Janssen
L
L
Ludovic Courtès wrote on 12 Dec 2017 21:22
(name . Roel Janssen)(address . roel@gnu.org)(address . 29676@debbugs.gnu.org)
871sjzitmm.fsf@gnu.org
Roel Janssen <roel@gnu.org> skribis:

Toggle quote (18 lines)
> Ludovic Courtès writes:
>
>> Hi,
>>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> I attached the build log. The relevant bit is this:
>>>
>>> actual-error:
>>> + (srfi-34
>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>>> result: FAIL
>>
>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
>> memory corruption, presumably in the daemon.
>
> The daemon used in the test, or the daemon used to do the package build?

The daemon under test (within the build environment).

Toggle quote (10 lines)
>> I suppose the failure random, isn’t it?
>
> I ran it again, and I've got the same error:
>
> actual-error:
> + (srfi-34
> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)
>
> So that's either a very funny coincidence, or it's a structural problem.

It’s better if it’s not random. :-)

Toggle quote (2 lines)
> Do you have any suggestions for how I can debug this problem?

Assuming the failure also happens when you run “make check” outside the
build container (in the failed build tree), can you add ‘valgrind’ in
‘test-env’? Specifically, in ‘test-env’, look for the line that invokes
‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind
guix-daemon’.

Ludo’.
L
L
Ludovic Courtès wrote on 20 Dec 2017 14:11
(name . Roel Janssen)(address . roel@gnu.org)(address . 29676@debbugs.gnu.org)
87ind1y262.fsf@gnu.org
Hi Roel,

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (2 lines)
> Roel Janssen <roel@gnu.org> skribis:

[...]

Toggle quote (32 lines)
>>>> actual-error:
>>>> + (srfi-34
>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>>>> result: FAIL
>>>
>>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
>>> memory corruption, presumably in the daemon.
>>
>> The daemon used in the test, or the daemon used to do the package build?
>
> The daemon under test (within the build environment).
>
>>> I suppose the failure random, isn’t it?
>>
>> I ran it again, and I've got the same error:
>>
>> actual-error:
>> + (srfi-34
>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)
>>
>> So that's either a very funny coincidence, or it's a structural problem.
>
> It’s better if it’s not random. :-)
>
>> Do you have any suggestions for how I can debug this problem?
>
> Assuming the failure also happens when you run “make check” outside the
> build container (in the failed build tree), can you add ‘valgrind’ in
> ‘test-env’? Specifically, in ‘test-env’, look for the line that invokes
> ‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind
> guix-daemon’.

Did you manage to gather more info?

Thanks,
Ludo’.
R
R
Roel Janssen wrote on 21 Dec 2017 15:55
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29676@debbugs.gnu.org)
87vah0ruyr.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (42 lines)
> Hi Roel,
>
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> Roel Janssen <roel@gnu.org> skribis:
>
> [...]
>
>>>>> actual-error:
>>>>> + (srfi-34
>>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>>>>> result: FAIL
>>>>
>>>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
>>>> memory corruption, presumably in the daemon.
>>>
>>> The daemon used in the test, or the daemon used to do the package build?
>>
>> The daemon under test (within the build environment).
>>
>>>> I suppose the failure random, isn’t it?
>>>
>>> I ran it again, and I've got the same error:
>>>
>>> actual-error:
>>> + (srfi-34
>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)
>>>
>>> So that's either a very funny coincidence, or it's a structural problem.
>>
>> It’s better if it’s not random. :-)
>>
>>> Do you have any suggestions for how I can debug this problem?
>>
>> Assuming the failure also happens when you run “make check” outside the
>> build container (in the failed build tree), can you add ‘valgrind’ in
>> ‘test-env’? Specifically, in ‘test-env’, look for the line that invokes
>> ‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind
>> guix-daemon’.
>
> Did you manage to gather more info?

No. When I run "make check -k" many tests fail. So my idea is to
create a custom Guix package with valgrind in its inputs to let
guix-daemon build that.

Kind regards,
Roel Janssen
L
L
Ludovic Courtès wrote on 21 Dec 2017 16:01
(name . Roel Janssen)(address . roel@gnu.org)(address . 29676@debbugs.gnu.org)
874lok5dmm.fsf@gnu.org
Roel Janssen <roel@gnu.org> skribis:

Toggle quote (46 lines)
> Ludovic Courtès writes:
>
>> Hi Roel,
>>
>> ludo@gnu.org (Ludovic Courtès) skribis:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>
>> [...]
>>
>>>>>> actual-error:
>>>>>> + (srfi-34
>>>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>>>>>> result: FAIL
>>>>>
>>>>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
>>>>> memory corruption, presumably in the daemon.
>>>>
>>>> The daemon used in the test, or the daemon used to do the package build?
>>>
>>> The daemon under test (within the build environment).
>>>
>>>>> I suppose the failure random, isn’t it?
>>>>
>>>> I ran it again, and I've got the same error:
>>>>
>>>> actual-error:
>>>> + (srfi-34
>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)
>>>>
>>>> So that's either a very funny coincidence, or it's a structural problem.
>>>
>>> It’s better if it’s not random. :-)
>>>
>>>> Do you have any suggestions for how I can debug this problem?
>>>
>>> Assuming the failure also happens when you run “make check” outside the
>>> build container (in the failed build tree), can you add ‘valgrind’ in
>>> ‘test-env’? Specifically, in ‘test-env’, look for the line that invokes
>>> ‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind
>>> guix-daemon’.
>>
>> Did you manage to gather more info?
>
> No. When I run "make check -k" many tests fail.

In a fresh checkout? If many tests fail, then there’s probably
something wrong with the environment, such as guix-daemon failing to
start or something. Could you check the logs?

Thanks,
Ludo’.
R
R
Roel Janssen wrote on 21 Dec 2017 17:49
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29676@debbugs.gnu.org)
87tvwkc9g1.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (52 lines)
> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hi Roel,
>>>
>>> ludo@gnu.org (Ludovic Courtès) skribis:
>>>
>>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>> [...]
>>>
>>>>>>> actual-error:
>>>>>>> + (srfi-34
>>>>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>>>>>>> result: FAIL
>>>>>>
>>>>>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
>>>>>> memory corruption, presumably in the daemon.
>>>>>
>>>>> The daemon used in the test, or the daemon used to do the package build?
>>>>
>>>> The daemon under test (within the build environment).
>>>>
>>>>>> I suppose the failure random, isn’t it?
>>>>>
>>>>> I ran it again, and I've got the same error:
>>>>>
>>>>> actual-error:
>>>>> + (srfi-34
>>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)
>>>>>
>>>>> So that's either a very funny coincidence, or it's a structural problem.
>>>>
>>>> It’s better if it’s not random. :-)
>>>>
>>>>> Do you have any suggestions for how I can debug this problem?
>>>>
>>>> Assuming the failure also happens when you run “make check” outside the
>>>> build container (in the failed build tree), can you add ‘valgrind’ in
>>>> ‘test-env’? Specifically, in ‘test-env’, look for the line that invokes
>>>> ‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind
>>>> guix-daemon’.
>>>
>>> Did you manage to gather more info?
>>
>> No. When I run "make check -k" many tests fail.
>
> In a fresh checkout? If many tests fail, then there’s probably
> something wrong with the environment, such as guix-daemon failing to
> start or something. Could you check the logs?

Indeed. I found out that guix-daemon couldn't start because I didn't
set --localstatedir properly. I "make check" again and that yields the
same issue with tests/store.scm.

However, upon changing test-env to include valgrind, more tests fail
again because of a problem accessing the daemon-socket.

So I manually started the guix-daemon with --disable-chroot and
prepended valgrind --leak-check=full to it. Then I ran:
$ guile -s tests/store.scm

Which yielding many more failures.
Then:
$ make check

Which also yielded more test failures.

I don't think the memory problem is in the log, but at least it shows
that we should have a look at the memory allocation of guix-daemon.

Kind regards,
Roel Janssen
Attachment: valgrind.log
R
R
Roel Janssen wrote on 21 Dec 2017 20:53
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29676@debbugs.gnu.org)
87inczhn78.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (55 lines)
> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hi Roel,
>>>
>>> ludo@gnu.org (Ludovic Courtès) skribis:
>>>
>>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>> [...]
>>>
>>>>>>> actual-error:
>>>>>>> + (srfi-34
>>>>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1071090>)
>>>>>>> result: FAIL
>>>>>>
>>>>>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a
>>>>>> memory corruption, presumably in the daemon.
>>>>>
>>>>> The daemon used in the test, or the daemon used to do the package build?
>>>>
>>>> The daemon under test (within the build environment).
>>>>
>>>>>> I suppose the failure random, isn’t it?
>>>>>
>>>>> I ran it again, and I've got the same error:
>>>>>
>>>>> actual-error:
>>>>> + (srfi-34
>>>>> + #<condition &nix-protocol-error [message: "path `dtmp/guix-tests/store/462z3fnl7bs44vp9s97jyg1z74nsfvly-tar' is not in the Nix store" status: 1] 1754ed0>)
>>>>>
>>>>> So that's either a very funny coincidence, or it's a structural problem.
>>>>
>>>> It’s better if it’s not random. :-)
>>>>
>>>>> Do you have any suggestions for how I can debug this problem?
>>>>
>>>> Assuming the failure also happens when you run “make check” outside the
>>>> build container (in the failed build tree), can you add ‘valgrind’ in
>>>> ‘test-env’? Specifically, in ‘test-env’, look for the line that invokes
>>>> ‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind
>>>> guix-daemon’.
>>>
>>> Did you manage to gather more info?
>>
>> No. When I run "make check -k" many tests fail.
>
> In a fresh checkout? If many tests fail, then there’s probably
> something wrong with the environment, such as guix-daemon failing to
> start or something. Could you check the logs?
>
> Thanks,
> Ludo’.

Indeed. I found out that guix-daemon couldn't start because I didn't
set --localstatedir properly. I "make check" again and that yields the
same issue with tests/store.scm.

However, upon changing test-env to include valgrind, more tests fail
again because of a problem accessing the daemon-socket.

So I manually started the guix-daemon with --disable-chroot and
prepended valgrind --leak-check=full to it. Then I ran:
$ guile -s tests/store.scm

Which yielding many more failures.
Then:
$ make check

Which also yielded more test failures. But at least I have a valgrind
log now, which I uploaded here:

I don't think the memory problem is in the log, but at least it shows
that we should have a look at the memory allocation of guix-daemon.
Sometimes it seems to leak memory.

Kind regards,
Roel Janssen
L
L
Ludovic Courtès wrote on 22 Dec 2017 10:24
(name . Roel Janssen)(address . roel@gnu.org)(address . 29676@debbugs.gnu.org)
87lghv9ku7.fsf@gnu.org
Hello,

Roel Janssen <roel@gnu.org> skribis:

Toggle quote (14 lines)
> ==24971== 4,104 bytes in 1 blocks are possibly lost in loss record 351 of 365
> ==24971== at 0x4C2AAD6: malloc (in /gnu/store/18w3ykyqkcq5zp1qx17qhamkxlczzl0n-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==24971== by 0x4E719E3: sqlite3MemMalloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x4E4DB8B: sqlite3Malloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x4E51316: pcache1Alloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x4E6E71A: sqlite3BtreeCursor (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x4EA9053: sqlite3VdbeExec (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x4EB271E: sqlite3_step (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x4EB34D1: sqlite3_exec (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
> ==24971== by 0x426886: nix::LocalStore::openDB(bool) (local-store.cc:293)
> ==24971== by 0x42BEF4: nix::LocalStore::LocalStore(bool) (local-store.cc:169)
> ==24971== by 0x40A356: acceptConnection(int)::{lambda()#1}::operator()() const (nix-daemon.cc:755)
> ==24971== by 0x40E16B: std::_Function_handler<void (), acceptConnection(int)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871)

I suspect these “possibly lost” reports are false alarms.

Anyway, there’s no “invalid read” or “invalid write” report, which is
what we were looking for. :-/

Thanks,
Ludo’.
R
R
Roel Janssen wrote on 3 Jan 2018 18:59
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29676@debbugs.gnu.org)
87fu7m6cxs.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (23 lines)
> Hello,
>
> Roel Janssen <roel@gnu.org> skribis:
>
>> ==24971== 4,104 bytes in 1 blocks are possibly lost in loss record 351 of 365
>> ==24971== at 0x4C2AAD6: malloc (in /gnu/store/18w3ykyqkcq5zp1qx17qhamkxlczzl0n-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==24971== by 0x4E719E3: sqlite3MemMalloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4E4DB8B: sqlite3Malloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4E51316: pcache1Alloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4E6E71A: sqlite3BtreeCursor (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4EA9053: sqlite3VdbeExec (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4EB271E: sqlite3_step (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4EB34D1: sqlite3_exec (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x426886: nix::LocalStore::openDB(bool) (local-store.cc:293)
>> ==24971== by 0x42BEF4: nix::LocalStore::LocalStore(bool) (local-store.cc:169)
>> ==24971== by 0x40A356: acceptConnection(int)::{lambda()#1}::operator()() const (nix-daemon.cc:755)
>> ==24971== by 0x40E16B: std::_Function_handler<void (), acceptConnection(int)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871)
>
> I suspect these “possibly lost” reports are false alarms.
>
> Anyway, there’s no “invalid read” or “invalid write” report, which is
> what we were looking for. :-/

Indeed. There are some 'definitely lost' reports as well, but these are
very small.

I can't seem to reproduce this on my laptop, which is strange because
the machine I do get the test failure on has ECC memory, and my laptop
doesn't have that.

Kind regards,
Roel Janssen
R
R
Roel Janssen wrote on 3 Feb 2018 01:13
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29676-close@debbugs.gnu.org)
87po5nhqv3.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (26 lines)
> Hello,
>
> Roel Janssen <roel@gnu.org> skribis:
>
>> ==24971== 4,104 bytes in 1 blocks are possibly lost in loss record 351 of 365
>> ==24971== at 0x4C2AAD6: malloc (in /gnu/store/18w3ykyqkcq5zp1qx17qhamkxlczzl0n-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==24971== by 0x4E719E3: sqlite3MemMalloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4E4DB8B: sqlite3Malloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4E51316: pcache1Alloc (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4E6E71A: sqlite3BtreeCursor (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4EA9053: sqlite3VdbeExec (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4EB271E: sqlite3_step (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x4EB34D1: sqlite3_exec (in /gnu/store/6d4ihp7xbdh3a0ffbpm5n45q4v3w0l35-sqlite-3.19.3/lib/libsqlite3.so.0.8.6)
>> ==24971== by 0x426886: nix::LocalStore::openDB(bool) (local-store.cc:293)
>> ==24971== by 0x42BEF4: nix::LocalStore::LocalStore(bool) (local-store.cc:169)
>> ==24971== by 0x40A356: acceptConnection(int)::{lambda()#1}::operator()() const (nix-daemon.cc:755)
>> ==24971== by 0x40E16B: std::_Function_handler<void (), acceptConnection(int)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871)
>
> I suspect these “possibly lost” reports are false alarms.
>
> Anyway, there’s no “invalid read” or “invalid write” report, which is
> what we were looking for. :-/
>
> Thanks,
> Ludo’.

So it seems that this issue has resolved itself. Notably, this bug
disappeared after a software update on the storage system that provides
the /gnu filesystem mount (NFS).

So this makes me think that it wasn't a problem in the guix-daemon.

Kind regards,
Roel Janssen
?