On 10-10-24 11:16, Konstantin Belousov wrote:
If you can determine not just the number of taken locks, but also the
specific locks that were taken, perhaps you can check that this is
the libc exit lock?
For the moment I've turned off the check for FreeBSD 15 and above.
At present the ExeCo
On 09-10-24 08:50, Konstantin Belousov wrote:
Perhaps you can check for the presence of the symbol exit@FBSD_1.0 in the
backtrace to determine the situation.
We don't read .gnu.version and the version number hasn't changed as far
as I can see.
I can check osreldate to get an idea of the
>
>
> I can probably check whether it's the main thread (I assume that this code
> doesn't run on subsidiary threads)
>
No it looks like it can be any thread.
A+
Paul
>
> On Wed, 9 Oct 2024 at 09:08, Konstantin Belousov
> wrote:
>
On Wed, Oct 09, 2024 at 06:35:08AM +, Paul Floyd wrote:
> > The biggest problem is with Helgrind. All apps now generate an extra
> error
> >
> > ==68593== Thread #1: Exiting thread still holds 1 l
Hi
I don't often update my 15-0-CURRENT VM. I did last week and I'm getting
several issues.
Firstly, a bit annoying, both pkg and ksh93 fail to run, giving.
ld-elf.so.1: Shared object "libmd.so.6" not found, required by "ksh93"
Next I'm getting a lot of new Valgrind test failures. I haven't d
On 04-04-24 05:49, FreeBSD User wrote:
Hello,
I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do
not allow me
to judge whether the described
On 05-02-24 17:02, Brooks Davis wrote:
Could you do a quick test with an exe linked to libsys but not libc running
under Valgrind memcheck, please?
Could you suggest a more concrete example?
This little example seems to be OK
void _start(void)
{
_exit(0);
}
However I do see quite a
Hi
> On 5 Feb 2024, at 17:02, Brooks Davis wrote:
>
>
>>> 2. It simplifies the implementation of restrictions on system calls such
>>> as those implemented by OpenBSD's msyscall(2)
>>> (https://man.openbsd.org/msyscall.2).
>>
>> That's one to ignore for tools that make syscalls out
On 02/02/2024 23:31, Brooks Davis wrote:
TL;DR: The implementation of system calls is moving to a seperate
library (libsys). No changes are required to existing software (except
to ensure that libsys is present when building custom disk images).
Code:https://github.com/freebsd/freebsd-src/pull
On 27-02-23 19:19, FreeBSD User wrote:
Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23
main-n261147-b8bb73ab724b: Sun Feb 26
17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13).
Building an appliance based on 13-STABLE sources, a customized kernel via
nanoBSD, s
On 04-01-23 11:24, Konstantin Belousov wrote:
On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote:
On 30/12/2022 01:54, Konstantin Belousov wrote:
The backtrace is needed to make a further analysis.
Any suggestions for getting a backtrace? I get the panic booting either the
inst
On 28-12-22 18:12, Ronald Klop wrote:
I've had success to capture errors by recording the screen with my phone
and playing back on slow speed.
Another option might be to enable serial port for the console of the
guest and capture the output. But I don't know if the default ISO uses
that a
On 28-12-22 18:05, Graham Perrin wrote:
If the guest has more than CPU, try reducing to one.
A step further: try booting the guest in safe mode.
Neither of those changed anything (I was using 2 CPUs)
A+
Paul
Hi
For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a
VirtualBox VM. I've tried both booting from iso image and the vmdk
image. I get a kernel panic
The host is running 13.1-RELEASE-p3 amd64
No problems with 14.0-CURRENT amd64 guests.
I haven't been able to see the last m
14 matches
Mail list logo
