The intention behind the iterator was to avoid needing to allocate the
symbols, but in practice we need to allocate them anyway since we need
to reverse their order and don't have random access. The alternative
would be an N^2 algorithm.
In practice this isn't that bad, because even if the allocation fails,
we'll still end up printing the address, so the user still ends up with
the necessary information to reconstruct the crash. I don't think it's
worth it to try to set up some kind of ring buffer or return partial
results on failure, but may revisit this.
This fix reveals another bug--we need to display the inline site syms in
the reverse of the encoded order. The parent/child relationships are
actually encoded on the inline sites, but it's likely a bit fragile to
try to trace those, and also more complex. As long as there aren't
multiple matches this is fine, and if there are, tracing the parent/child
chain won't work anyway.
Apple's ld emit N_BNSYM and N_ENSYM to mark the start and end of
functions, while ld64.lld doesn't.
This resulted in MachOFile.load bailing out on unsupported STABS
layout when the linker used is ld64.lld.
This commit supports both layouts.
I hit an unexpected errno 30 on macos attempting to call createFile on a
directory in PATH. errno 30 is EROFS, this change propagates that error
as error.ReadOnlyFileSystem.
`resolveAddresses` now also works if some calls to `getDwarfForAddress`
fail with `error.MissingDebugInfo`; the affected source location is set
to `.invalid`.
This makes fuzzing work with `ReleaseSafe` for Mach-O.
- delete std.Thread.Futex
- delete std.Thread.Mutex
- delete std.Thread.Semaphore
- delete std.Thread.Condition
- delete std.Thread.RwLock
- delete std.once
std.Thread.Mutex.Recursive remains... for now. it will be replaced with
a special purpose mechanism used only by panic logic.
std.Io.Threaded exposes mutexLock and mutexUnlock for the advanced case
when you need to call them directly.
- remove error.SharingViolation from all error sets since it has the
same meaning as FileBusy
- add error.FileBusy to CreateFileAtomicError and ReadLinkError
- update dirReadLinkWindows to use NtCreateFile and NtFsControlFile and
integrate with cancelation properly.
- move windows CTL_CODE constants to the proper namespace
- delete os.windows.ReadLink
The most interesting thing here is the replacement of the pthread futex
implementation with an implementation based on thread park/unpark APIs.
Thread parking tends to be the primitive provided by systems which do
not have a futex primitive, such as NetBSD, so this implementation is
far more efficient than the pthread one. It is also useful on Windows,
where `RtlWaitOnAddress` is itself a userland implementation based on
thread park/unpark; we can implement it ourselves including support for
features which Windows' implementation lacks, such as cancelation and
waking a number of waiters with 1<n<infinity.
Compared to the pthread implementation, this thread-parking-based one
also supports full robust cancelation. Thread parking also turns out to
be useful for implementing `sleep`, so is now used for that on Windows
and NetBSD.
This commit also introduces proper cancelation support for most Windows
operations. The most notable omission right now is DNS lookups through
`GetAddrInfoEx`, just because they're a little more work due to having
a unique cancelation mechanism---but the machinery is all there, so I'll
finish gluing it together soon.
As of this commit, there are very few parts of `Io.Threaded` which do
not support full robust cancelation. The only ones which actually really
matter (because they could block for a prolonged period of time) are DNS
lookups on Windows (as discussed above) and futex waits on WASM.
It's better to avoid references to this global variable, but, in the
cases where it's needed, such as in std.debug.print and collecting stack
traces, better to share the same instance.
instead, allow the user to set it as a field.
this fixes a bug where leak printing and error printing would run tty
config detection for stderr, and then emit a log, which is not necessary
going to print to stderr.
however, the nice defaults are gone; the user must explicitly assign the
tty_config field during initialization or else the logging will not have
color.
related: https://github.com/ziglang/zig/issues/24510
Mason Remaley