libeatmydata causing odd stack trace for golang app executing as post-build-hook

[colemickens]

Hi. I'm working on a new tool to manage/upload to Nix binary caches. One of it's features is to queue uploads via a post-build-hook, allowing for uploading build artifacts that would otherwise be difficult in some specific build scenarios.

In testing, I found that it worked in most places, but one of my final real world usage tests was to use aarch64.nixos.community to build somethings and cache them. However, I have run into this issue:

When my application executes under nix-daemon, as it invokes the post-build-hook, the child process, my application, crashes with a backtrace pointing to libeatmydata:

Core was generated by `/nix/store/qbbmsd6ldg1x4laxpa0128l5li6h79cb-nnnnn-16228faf4e6935a9cd4e9edc2621c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000ffffaa2d21ac in dlsym () from /nix/store/akyy80zkwyiy0n51kc4vx0qpxma77701-glibc-2.30/lib/libdl.so.2
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /nix/store/qbbmsd6ldg1x4laxpa0128l5li6h79cb-nnnnn-16228faf4e6935a9cd4e9edc2621cca7cca0b725/bin/nnnnnn.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) bt
#0  0x0000ffffaa2d21ac in dlsym () from /nix/store/akyy80zkwyiy0n51kc4vx0qpxma77701-glibc-2.30/lib/libdl.so.2
#1  0x0000ffffaa48195c in eatmydata_init () from /nix/store/6kjxy32r1qzhsdm2h77ljg2nzxhdsiv1-libeatmydata-105/lib/libeatmydata.so
#2  0x0000ffffaa4a2298 in call_init () from /nix/store/6diwpjpcjz497wxwj4mdbfg8hl1hi8l2-glibc-2.32/lib/ld-linux-aarch64.so.1
#3  0x0000ffffaa4a2394 in _dl_init () from /nix/store/6diwpjpcjz497wxwj4mdbfg8hl1hi8l2-glibc-2.32/lib/ld-linux-aarch64.so.1
#4  0x0000ffffaa495048 in _dl_start_user () from /nix/store/6diwpjpcjz497wxwj4mdbfg8hl1hi8l2-glibc-2.32/lib/ld-linux-aarch64.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

This backtrace doesn't appear to be anywhere near my code, and I'm guessing is related the this piece of the community box configuration:

https://github.com/nix-community/aarch64-build-box/blob/709f2f5bf678c83292d4058bea7944de56328040/configuration.nix#L160-L164

I'm mostly filing this because I'm looking for clues or hints as to what's going on. Is this something I can mitigate, somehow, in the package derivation? (Maybe I can do something to the binary to keep it from being affected negatively by libeatmydata?)

(I mention go in the issue title, not because I've successfully tested with a non-go app, but just because I've had issues with other nix things like patchelf with Go in the past.)

[colemickens]

Thanks to @tilpner for recommending that I could just call unset LD_PRELOAD in my script ahead of my own program, which successfully works around the issue caused by libeatmydata.