Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Nov 2024 15:21:20 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Guido Falsi <mad@madpilot.net>
Cc:        Dimitry Andric <dim@FreeBSD.org>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@FreeBSD.org>, ports@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: port binary dumping core on recent head in poudriere
Message-ID:  <D14FF56C-506F-4168-91BC-1F10937B943F@yahoo.com>
In-Reply-To: <1004a753-9a3c-4aa2-bfa8-4a0c471fe3ea@madpilot.net>
References:  <aa597431-54a8-4cde-8d4f-b75040b59bae@madpilot.net> <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org> <5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0@madpilot.net> <f9e32784-226a-4e1e-a24b-62f5e6d3d765@madpilot.net> <E4616829-D2DE-4EAF-B971-1EDA8B447F13@FreeBSD.org> <7c9c3cf5-bbd1-4642-8d04-33aa07a4db02@madpilot.net> <9df256a8-c6ed-46d9-b955-fc2657c12d36@madpilot.net> <5c502054-7353-4a1e-8350-c403482e9c0d@madpilot.net> <a203a89f-2eb7-4220-8dfb-648cd46fc6bb@madpilot.net> <3127C3BA-FC93-4636-ADDB-89518DE9C60D@FreeBSD.org> <86ed2zsp6l.fsf@ltc.des.dev> <5f24a570-26e0-4c0a-817f-591a234fd07b@madpilot.net> <5918C6A1-8FDB-40CA-8C86-EB7B7BE75A2E@yahoo.com> <86ed2zc8r5.fsf@ltc.des.dev> <45098ccf-4dc6-426c-849a-c923805d6723@madpilot.net> <F64DB4E9-A210-4E1F-B333-C597F3DBED54@yahoo.com> <38658C0D-CA33-4010-BBE1-E68D253A3DF7@FreeBSD.org> <1004a753-9a3c-4aa2-bfa8-4a0c471fe3ea@madpilot.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 25, 2024, at 14:23, Guido Falsi <mad@madpilot.net> wrote:

> On 25/11/24 23:15, Dimitry Andric wrote:
>> On 25 Nov 2024, at 23:12, Mark Millard <marklmi@yahoo.com> wrote:
>>>=20
>>> On Nov 25, 2024, at 13:27, Guido Falsi <mad@madpilot.net> wrote:
>>>=20
>>>> On 25/11/24 22:18, Dag-Erling Sm=C3=B8rgrav wrote:
>>>>> Mark Millard <marklmi@yahoo.com> writes:
>>>>>> Guido Falsi <mad@madpilot.net> writes:
>>>>>>> On 25/11/24 09:17, Dag-Erling Sm=C3=B8rgrav wrote:
>>>>>>>> Dimitry Andric <dim@FreeBSD.org> writes:
>>>>>>>>> Probably best to create a bugzilla ticket, but as I said =
before, I
>>>>>>>>> cannot reproduce this.
>>>>>>>> I can.  My builder is running 15 and sees segfaults while =
building
>>>>>>>> packages for 14 and 15 but not for 13.
>>>>>>> BTW removing optimizations (CPUTYPE) for only the affected ports =
made
>>>>>>> guile2 work again. Did not solve the issue with sassc though.  =
[...]
>>>>>>> I'm also using ccache, but that does not look relevant.
>>>>>> I've never used ccache or analogous and get the libsass.so.1.0.0
>>>>>> .got.plt corruption that I've reported on the lists anyway.
>>>>> I don't use ccache or optimizations.  Here's an example of sassc
>>>>> segfaulting in a 14.1-RELEASE-p6 jail:
>>>>>  =
https://pkg.des.dev/logs/data/14amd64-default/2024-11-24_19h29m04s/logs/er=
rors/plasma5-breeze-gtk-5.27.11.log
>>>>> which matches the following entry from `/var/log/messages`:
>>>>>  Nov 24 21:23:06 pkg kernel: pid 71277 (sassc), jid 253, uid =
65534: exited on signal 11 (core dumped)
>>>>> The poudriere host is a bhyve VM with 48 cores and 192 GB RAM on a
>>>>> 32c/64t AMD EPYC 7502P with 256 GB RAM.
>>>>=20
>>>> I sincerely hope this is not relevant but my CPU is also AMD: AMD =
Ryzen 5 5600G
>>>=20
>>> The amd64 system type that I have access to and used
>>> for my testing:
>>>=20
>>> AMD 7950X3D (16 core, 32 thread, so 32 FreeBSD-cpus) with 192 =
GiBytes of RAM
>> I'm on Intel, and I don't see any crashes at all. So, are we looking =
at some CPU specific issue here?
>=20
> We can't say for sure, but we definitely have all people reporting the =
issue on the same CPU brand, so it's some indication I guess.
>=20
> I was hoping it would not come to this because I suspect such issues =
are quite difficult to diagnose.

Unfortunately, for amd64 I only have access to:

) An old ThreadRipper 1950X system (untested so far)
) The 7950X3D system

No Intel systems.

If someone had both AMD and Intel and could have
boot&operate media that should work for both, say
USB that can be simply moved between machines,
running test on both would be appropriate.
(Implication: the media not being tailored to the
cpu specifics so the same system software is
tested in both places.)

I'll note that the media in my context is PCIe Optane,
ZFS based. I could try a U.2 Optane in a PCIe adaptor
that has UFS instead for building textproc/libsass .
(The U.2 content is an basically a rsync of the ZFS
Optane media's live directory tree, with node naming
and such adjusted afterwards.)

What do other folks have for the file system(s)
involved?

=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D14FF56C-506F-4168-91BC-1F10937B943F>