[Bug 254458] emulators/virtualbox-ose some versions of FreeBSD do not work, if started from a snapshot that was saved whilst the working FreeBSD guest ran

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254458 Graham Perrin changed: What|Removed |Added Summary|Some versions of FreeBSD do |emulators/virtualbox-ose

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 --- Comment #6 from maskray --- (In reply to Konstantin Belousov from comment #5) Ah, nice, thanks. Fixing libc.so should suffice for sanitizers - sanitizers need dlsym(RTLD_NEXT, ...) and cannot be used with -static (libc.a). -- You are

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 --- Comment #5 from Konstantin Belousov --- (In reply to maskray from comment #4) No, I do not mean initial exec vs dynamic tls. I mean, dl_iterate_phdr() dlpi_tls_data value in static _binary_ vs dynamic binary. The patch I posted is

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 --- Comment #4 from maskray --- I want to use dlpi_tls_data for static TLS blocks (from the main executable and initially loaded shared objects). Working dynamic TLS blocks will be nice to have for consistency. I will try calling

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 --- Comment #3 from Konstantin Belousov --- (In reply to Brandon Bergren from comment #2) The drv reallocation should not affect dl_iterate_phdr() result. That said, for dl_iterate_phdr() for dynamic binary, the fix is indeed simple: diff

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 --- Comment #2 from Brandon Bergren --- It looks like on ours, computing the address with __tls_get_addr will as a side effect do any deferred allocations / dtv resizing due to the tls_dtv_generation check happening at that time. Not sure

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 --- Comment #1 from maskray --- Note: dlpi_tls_data is essentially __tls_get_addr((tls_mod_off_t[]){1,0}) on both TLS Variant I and Variant II architectures. musl has the same problem. Rich has acknoledged the problem and will fix it

[Bug 254774] [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254774 Bug ID: 254774 Summary: [rtld] dl_iterate_phdr: dlpi_tls_data should be the iterated module's TLS image instead of TLS initialization image Product: Base System

[Bug 254432] ctld won't start correctly at boot

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254432 Edward Tomasz Napierala changed: What|Removed |Added CC||tr...@freebsd.org ---

[Bug 232397] ctld does not depend on sysctl.conf being evaluated

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232397 Edward Tomasz Napierala changed: What|Removed |Added Assignee|b...@freebsd.org|tr...@freebsd.org

Problem reports for b...@freebsd.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 254721] Swap on ZFS can crash server in high memory usage conditions

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254721 Andriy Gapon changed: What|Removed |Added Assignee|f...@freebsd.org |b...@freebsd.org --- Comment #1

[Bug 231974] processes stuck in D State

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231974 Christos Chatzaras changed: What|Removed |Added Resolution|--- |Overcome By Events

[Bug 254763] grep very slow with 13.0-RC4

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254763 Christos Chatzaras changed: What|Removed |Added Hardware|Any |amd64 -- You are receiving

[Bug 254763] grep very slow with 13.0-RC4

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254763 Bug ID: 254763 Summary: grep very slow with 13.0-RC4 Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects

[Bug 254695] Hyper-V: Kernel Panic: Assertion in_epoch(net_epoch_preempt) failed at netinet/tcp_lro.c:915

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254695 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|virtualizat...@freebsd.org -- You