Richard Feldman (Dec 05 2025 at 14:16): Richard Feldman (Dec 05 2025 at 14:16):https://github.com/roc-lang/roc/pull/8565 failed on Nix checks only, but there's no error message and I'm not sure how to debug :sweat_smile:
I'm going to merge because it has some important fixes and is prone to merge conflicts, plus I don't see why anything should have changed in terms of Nix :raised:
can anyone who has Nix set up try to reproduce that locally?
Anton (Dec 05 2025 at 14:45):I'll take a quick look
Anton (Dec 05 2025 at 15:04):It passes now https://github.com/roc-lang/roc/pull/8575 , I did not change anything :p
There was also nothing in your failing check output that showed what was going wrong, I guess we'll see if it pops up again.
Richard Feldman (Dec 06 2025 at 18:05):I think I found a fix - https://github.com/roc-lang/roc/pull/8579 - I believe the problem was that we were rebuilding the roc binary before each fx test, to prevent staleness, and this resulted in too much disk usage for the Nix environment, resulting in an error with no clear error message.
Richard Feldman (Dec 06 2025 at 18:06):however, that PR is now failing on a valgrind error that suggests maybe we install a non-stripped ld.so equivalent in that environment?
debug: reported NIL problems
debug: processing snapshot file: /home/runner/work/roc/roc/test/snapshots/expr_no_space_dot_int.md
debug: Generating snapshot for: /home/runner/work/roc/roc/test/snapshots/expr_no_space_dot_int.md
debug: processing snapshot file: /home/runner/work/roc/roc/test/snapshots/can_import_exposing_types.md
debug: Generating snapshot for: /home/runner/work/roc/roc/test/snapshots/can_import_exposing_types.md
==6829==
==6829== HEAP SUMMARY:
==6829== in use at exit: 0 bytes in 0 blocks
==6829== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==6829==
==6829== All heap blocks were freed -- no leaks are possible
==6829==
==6829== For lists of detected and suppressed errors, rerun with: -s
==6829== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==6906== Memcheck, a memory error detector
==6906== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==6906== Using Valgrind-3.26.0 and LibVEX; rerun with -h for copyright info
==6906== Command: ./zig-out/bin/roc --no-cache test/str/app.roc
==6906==
valgrind: Fatal error at startup: a function redirection
valgrind: which is mandatory for this platform-tool combination
valgrind: cannot be set up. Details of the redirection are:
valgrind:
valgrind: A must-be-redirected function
valgrind: whose name matches the pattern: memcmp
valgrind: in an object with soname matching: ld-linux-x86-64.so.2
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
valgrind: that exports the above-named function using the standard
valgrind: calling conventions for this platform. The package you need
valgrind: to install for fix (1) is called
valgrind:
valgrind: On Debian, Ubuntu: libc6-dbg
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind: Note that if you are debugging a 32 bit process on a
valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo
valgrind: package (e.g. libc6-dbg:i386).
valgrind:
valgrind: Cannot continue -- exiting now. Sorry
Anton (Dec 08 2025 at 10:42):Looks like it's fixed :)
Richard Feldman (Dec 08 2025 at 14:32):oh yeah Claude had a suggested fix in a recent PR, and it ended up resolving it
Last updated: Dec 21 2025 at 12:15 UTC