search for: is_read

...> >> Does “0x00486000000025df” like a reasonable content of a shadow cell? > > > > Yes, it looks like a reasonable shadow: > > // Shadow (from most significant bit): > // freed : 1 > // tid : kTidBits > // is_atomic : 1 > // is_read : 1 > // size_log : 2 > // addr0 : 3 > // epoch : kClkBits +Nico pointed to another failure: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9782/testReport/ThreadSanitizer/ThreadSanitizer/mmap_stress_cc/

I managed to get a build of the async Rust handle compiling on FreeBSD (although the cirrus CI appears to not actually run 'make check' on non-Linux machines, at least when run on my fork): https://gitlab.com/ebblake/libnbd/-/jobs/4985192286 However, I'd really like Tage's review on patch 2 to see if my Rust makes sense. Eric Blake (2): maint: Favor 4-space indent in .rs files

Hm, I tried to reproduce this as well, but unsuccessfully. From the crash report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re