| View previous topic :: View next topic |
| Author |
Message |
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
 Posted: Fri Dec 22, 2023 11:00 pm Post subject: [Solved]Pipewire failing to compile |
 |
|
For some reason pipewire fails to compile. Here's the build.log. Let me know if I need to supply any more inforamtion.
Edit: It built one time. Now it won't rebuild. Not an issue with ram oc I set it back to default, and still no build.
Solved: It was an issue with libmysofa-1.3.2, and not building the necessary headers. I just made it an 9999 build, and it works.
Last edited by JustCauseWhyNot on Sun Mar 24, 2024 10:18 pm; edited 3 times in total |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1663
|
| Posted: Sat Dec 23, 2023 12:29 am Post subject: |
|
|
| Code: | | ../pipewire-1.0.0/spa/tools/spa-inspect.c:37:13: internal compiler error: Segmentation fault |
Likely this is an out of memory condition. Verify in dmesg and reduce MAKEOPTS jobs in make.conf if so. |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Sat Dec 23, 2023 1:46 am Post subject: |
|
|
| I'll try that out thank you. |
|
| Back to top |
|
|
myga
Tux's lil' helper
Joined: 12 Jun 2023
Posts: 99
|
| Posted: Sat Dec 23, 2023 4:03 am Post subject: |
|
|
That segfault is a result of a misused pointer somewhere that has to do with the function below. I would submit a bug report here https://gitlab.freedesktop.org/pipewire/pipewire/-/issues.
Build time error:
| Code: | FAILED: spa/tools/spa-inspect.p/spa-inspect.c.o
----snip-------
inspect.c.o -c ../pipewire-1.0.0/spa/tools/spa-inspect.c
during GIMPLE pass: uninit
../pipewire-1.0.0/spa/tools/spa-inspect.c: In function ‘print_param’:
../pipewire-1.0.0/spa/tools/spa-inspect.c:37:13: internal compiler error: Segmentation fault
37 | static void print_param(void *data, int seq, int res, uint32_t type, const void *result)
| ^~~~~~~~~~~ |
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/tools/spa-inspect.c?ref_type=heads
| Code: | static void print_param(void *data, int seq, int res, uint32_t type, const void *result)
{
switch (type) {
case SPA_RESULT_TYPE_NODE_PARAMS:
{
const struct spa_result_node_params *r = result;
if (spa_pod_is_object_type(r->param, SPA_TYPE_OBJECT_Format))
spa_debug_format(16, NULL, r->param);
else
spa_debug_pod(16, NULL, r->param);
break;
}
default:
break;
}
}
|
|
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Sat Dec 23, 2023 6:28 pm Post subject: |
|
|
| That would make more sense since I'm not running out of memory while compiling. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Sat Dec 23, 2023 7:59 pm Post subject: |
|
|
Please file a Gentoo bug (not an upstream PipeWire bug) with the build.log, meson-log.txt, and emerge --info. It is a bug in GCC if it ICEs deterministically and it's not caused by bad RAM or OOM or overclocking.
I can't reproduce it yet. Does this consistently fail with the same error message (exactly the same)? Also, what is -march=native for you? |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Sat Dec 23, 2023 8:52 pm Post subject: |
|
|
| Quote: | | Please file a Gentoo bug (not an upstream PipeWire bug) with the build.log, meson-log.txt, and emerge --info. |
I will. | Quote: | | Please file a Gentoo bug (not an upstream PipeWire bug) with the build.log, meson-log.txt, and emerge --info. |
Yes it does. | Quote: | | Also, what is -march=native for you? |
I believe it's -march=znver2. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Dec 23, 2023 9:48 pm Post subject: |
|
|
I just compiled it, no problem, I don't think it has anything to do with a "misused pointer"
The only difference I see is that I'm compiling for 64 bit not 32.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
myga
Tux's lil' helper
Joined: 12 Jun 2023
Posts: 99
|
| Posted: Sun Dec 24, 2023 3:25 am Post subject: |
|
|
| Anon-E-moose wrote: | I just compiled it, no problem, I don't think it has anything to do with a "misused pointer"
The only difference I see is that I'm compiling for 64 bit not 32. |
In general, the occurrence of a segfault in a program on a 32-bit system does not necessarily guarantee that the same program will experience a segfault on a 64-bit system, and vice versa.
Pointer Size and Memory Addressing: If the segfault is caused by improper use of pointers or memory addressing issues, it's possible that the behavior may differ between 32-bit and 64-bit systems. For example, if the program assumes a certain size for a pointer or if there are pointer arithmetic issues, these issues may manifest differently on systems with different pointer sizes.
Data Type Sizes: If the program makes assumptions about the sizes of data types (e.g., assuming an int is always 32 bits), it may lead to issues when transitioning between 32-bit and 64-bit systems. Code that relies on specific data type sizes might behave differently on systems with different architectures.
Library and System Calls: If the program interacts with system-specific libraries or makes assumptions about the behavior of system calls, differences in the underlying system architecture can lead to divergent behavior.
Memory Allocation and Alignment: Differences in memory alignment and allocation strategies between 32-bit and 64-bit systems may also impact program behavior. Code that relies on specific memory layout assumptions may behave differently.
Compiler and Compilation Flags: Compiler optimizations and flags can also play a role. Code that works without issues on one architecture might trigger problems when compiled for another architecture.
Endianness: While this is less likely to be a direct cause of a segfault, differences in endianness between architectures can potentially affect code that relies on specific byte orders. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Sun Dec 24, 2023 4:06 am Post subject: |
|
|
| The compiler is crashing, not pipewire itself. This may or may not be related to invalid code, but the compiler still shouldn't ICE. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Dec 24, 2023 10:42 am Post subject: |
|
|
Flacky source code will not cause gcc to segfault when compiling, it will trigger one or more errors/warnings.
It's not running the source code, it's compiling it.
If it errored out while running the compiled program, then maybe point fingers at the code and possibly compiler, but that's not the problem.
Gcc segfaults when compiling, is triggered by a hardware problem, cpu error, memory error, running out of memory, etc
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Last edited by Anon-E-moose on Sun Dec 24, 2023 10:47 am; edited 1 time in total |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Sun Dec 24, 2023 10:46 am Post subject: |
|
|
| No, there are occasionally bugs in GCC and sometimes they're triggered by invalid code. I report many over the year and they end up not hitting users because we catch them early. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Dec 24, 2023 10:55 am Post subject: |
|
|
Whatever, you must be right, never trust gcc.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Sun Dec 24, 2023 11:01 am Post subject: |
|
|
Clang has the same deal:
This is just how software is. Lots of testing before they get released helps to catch most of it. |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Tue Dec 26, 2023 2:17 am Post subject: |
|
|
| sam_ wrote: | Please file a Gentoo bug (not an upstream PipeWire bug) with the build.log, meson-log.txt, and emerge --info. It is a bug in GCC if it ICEs deterministically and it's not caused by bad RAM or OOM or overclocking.
I can't reproduce it yet. Does this consistently fail with the same error message (exactly the same)? Also, what is -march=native for you? |
It doesn't fail in the same place everytime, but it does fail the same way each time. |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Tue Dec 26, 2023 9:39 am Post subject: |
|
|
Right now it's failing to compile due to me creating an env | Code: | | MYMESONARGS="-Dlibmysofa=enabled" |
, and enabling it for pipewire. I've got libmysofa installed as multiliib so I don't know why it's failing to compile. I thought I had it off though when I wrote the post initially. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Tue Dec 26, 2023 3:25 pm Post subject: |
|
|
| Please do a memtest if it's failing inconsistently. |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Tue Dec 26, 2023 9:02 pm Post subject: |
|
|
| I've stress tested my ram using stressappteat, and running that for an hour consuming 30/31.2 GiB of ram. I've gotten zero errors, and havent had issues compiling other packages. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Tue Dec 26, 2023 10:28 pm Post subject: |
|
|
Please run memtest for at least 12 hours or so overnight, longer if you can. Online tests like stressapptest are not as rigorous and cannot test the whole region.
The fact it is non-deterministic and different files implies it's very likely to be HW. If it's not memory, it's likely overclocking or similar. |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Tue Dec 26, 2023 10:56 pm Post subject: |
|
|
| I'll do that. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1547
|
| Posted: Wed Dec 27, 2023 6:59 am Post subject: |
|
|
| JustCauseWhyNot wrote: | | I've stress tested my ram using stressappteat, and running that for an hour consuming 30/31.2 GiB of ram. I've gotten zero errors, and havent had issues compiling other packages. |
User space tests and tests that run under full OS booted cannot test all memory.
| Code: | emerge memtest86+
grub-mkconfig -o /boot/grub/grub.cfg |
Reboot into memtest86+ and test for at least 5, preferably 8 passes.
Best Regards,
Georgi |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Wed Dec 27, 2023 7:04 am Post subject: |
|
|
| Interesting. I didn't know that was a thing. Thank you. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1547
|
| Posted: Wed Dec 27, 2023 8:57 am Post subject: |
|
|
I just realized if this is a laptop with hybrid graphics you need to switch to the discrete GPU as well since the EFI firmware would otherwise reserve memory for the integrated GPI and it'll not be available for testing.
Best Regards,
Georgi |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Wed Dec 27, 2023 7:02 pm Post subject: |
|
|
| logrusx wrote: | I just realized if this is a laptop with hybrid graphics you need to switch to the discrete GPU as well since the EFI firmware would otherwise reserve memory for the integrated GPI and it'll not be available for testing.
Best Regards,
Georgi |
I'm using a desktop with a dgpu thankfully. But its good to keep in mind. |
|
| Back to top |
|
|
JustCauseWhyNot
Tux's lil' helper
Joined: 07 Dec 2021
Posts: 124
|
| Posted: Thu Jan 04, 2024 4:19 pm Post subject: |
|
|
| Would this article be how I want to create a memtest86+ efibootmgr entry? |
|
| Back to top |
|
|
|
Portage & Programming
