< gmaxwell>
are you sure it's allocations and not mmaped files
< luke-jr>
gmaxwell: well, things get real slow when I begin swapping
< luke-jr>
I'd expect mmap can't do that
< luke-jr>
thankfully, the actual code being executed is relatively small, I guess I can just start commenting out parts to see where the culprit is
< luke-jr>
(the wallet rescan logic specifically)
< luke-jr>
curiously, valgrind did report: crypto/common.h:48:22: runtime error: load of misaligned address 0x000046682d26 for type 'uint32_t', which requires 4 byte alignment
< luke-jr>
and it looks like our SHA2 code does such access without checking alignment. wonder why it works.
< luke-jr>
(but this is an older codebase, maybe already changed)
< gmaxwell>
that should be fixed. alignment isn't required on x86, so it works even though its undefined behavior.
< sipa>
luke-jr: which function is that?
< luke-jr>
SSSE3 definitely segfaulted when not aligned on my Haswell CPU, but that's another specific case :p
< gmaxwell>
luke-jr: yes, unaligned aligned simd reads can crash on x86.
< luke-jr>
gmaxwell: the fun part of that was that glibc did it for memcpy XD
< * luke-jr>
ended up just adding -mno-ssse3 to his CFLAGS
< gmaxwell>
wtf. memcpy has no alignment requirements.
< sipa>
gmaxwell: but memcpy may be implemented by casting pointers to int pointers and then assigning
< sipa>
(i assume that's what luke meant)
< luke-jr>
right
< * luke-jr>
should set a ulimit so he can test this without his system coming to a crawl when he steps away for a second :|
< bitcoin-git>
[bitcoin] danra opened pull request #11164: Fix boost headers included as user instead of system headers (master...fix/boost-system-includes) https://github.com/bitcoin/bitcoin/pull/11164