Re: cmake ftbfs on ppc64el (and ppc64)

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

On Fri, 2024-01-12 at 01:31 +0100, John Paul Adrian Glaubitz wrote:
> This has now been tracked down to the libuv upstream change that introduced 
> support
> for io_uring [1]. This regression is tracked now in a new issue for libuv [2].

The attached patch disables io_uring on ppc64 and ppc64el for the time being 
until
the upstream issue has been resolved.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From 3b6a1a14caeeeaf5510f2939a8e28ed9ba0ad968 Mon Sep 17 00:00:00 2001
From: Brad King 
Date: Sat, 13 Jan 2024 06:04:01 -0500
Subject: [PATCH] linux: disable io_uring on ppc64 and ppc64le (#4285)

Since `io_uring` support was added, libuv's signal handler randomly
segfaults on ppc64 when interrupting `epoll_pwait`.  Disable it
pending further investigation.

Issue: https://github.com/libuv/libuv/issues/4283
---
 src/unix/linux.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/unix/linux.c b/src/unix/linux.c
index 3c1313e7..4164e90d 100644
--- a/src/unix/linux.c
+++ b/src/unix/linux.c
@@ -463,6 +463,9 @@ static int uv__use_io_uring(void) {
 #elif defined(__arm__) && __SIZEOF_POINTER__ == 4
   /* See https://github.com/libuv/libuv/issues/4158. */
   return 0;  /* All 32 bits kernels appear buggy. */
+#elif defined(__powerpc64__) || defined(__ppc64__)
+  /* See https://github.com/libuv/libuv/issues/4283. */
+  return 0; /* Random SIGSEGV in signal handler. */
 #else
   /* Ternary: unknown=0, yes=1, no=-1 */
   static _Atomic int use_io_uring;
-- 
2.43.0

Re: cmake ftbfs on ppc64el (and ppc64)

[John Paul Adrian Glaubitz]

Hello,

On Thu, 2024-01-11 at 19:15 +0100, John Paul Adrian Glaubitz wrote:
> This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said 
> he
> would be looking into it. In case he comes up with a solution, I will report 
> it
> here.

This has now been tracked down to the libuv upstream change that introduced 
support
for io_uring [1]. This regression is tracked now in a new issue for libuv [2].

Adrian

> [1] 
> https://github.com/libuv/libuv/commit/d2c31f429b87b476a7f1344d145dad4752a406d4
> [2] https://github.com/libuv/libuv/issues/4283

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: cmake ftbfs on ppc64el (and ppc64)

[John Paul Adrian Glaubitz]

Hi Jeff,

On Thu, 2024-01-11 at 13:25 -0500, Jeffrey Walton wrote:
> > 
> It may be a good idea to give the CMake folks the first chance at the
> fix. It does not look like it has been reported to them:
> . Searching with
> 'ppc' and 'llvm' tags returned 0 hits:
> .
> (Maybe I missed it in their bug tracker).

It was actually reported upstream and this bug report also forwards to
the corresponding issue [1]. However, cmake upstream does not consider
it a bug on their side which is why they closed the bug.

Adrian

> [1] https://gitlab.kitware.com/cmake/cmake/-/issues/25500

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: cmake ftbfs on ppc64el (and ppc64)

[Jeffrey Walton]

On Thu, Jan 11, 2024 at 1:16 PM John Paul Adrian Glaubitz
 wrote:
>
> the bug is definitely still present and I'm therefore not sure whether
> downgrading the priority to normal is justified.
>
> On ppc64, cmake still crashes regularly when configuring the LLVM build
> for example [1]:
>
> -- Looking for pow in m - found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Looking for backtrace in execinfo
> Segmentation fault
>
> I have performed a local LLVM test build and obtained a backtrace with gdb
> which also indicates a crash in libuv:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x in ?? ()
> [Current thread is 1 (Thread 0x7fff811f6e60 (LWP 2635470))]
> (gdb) bt
> #0  0x in ?? ()
> #1  
> #2  0x7fff82eee784 in __GI_epoll_pwait (epfd=4, events=0x7fffd3808cc8, 
> maxevents=1024, timeout=-1, set=0x0) at 
> ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
> #3  0x7fff83545238 in uv__io_poll (loop=0x10015e8edd0, timeout=-1) at 
> ./src/unix/linux.c:1365
> #4  0x7fff8352aa84 in uv_run (loop=0x10015e8edd0, mode=UV_RUN_ONCE) at 
> ./src/unix/core.c:447
> #5  0x000132669d8c in cmExecuteProcessCommand (args=..., status=...) at 
> ./Source/cmExecuteProcessCommand.cxx:358
> #6  0x000132561d38 in InvokeBuiltinCommand (status=..., args=..., 
> command=@0x133045248: 0x1326682b0 
>  std::char_traits,
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> cmExecutionStatus&)>)
> at ./Source/cmState.cxx:420
> #7  operator() (status=..., args=..., __closure=) at 
> ./Source/cmState.cxx:430
> #8  std::__invoke_impl BuiltinCommand)::&, 
> cmExecutionStatus&)>&, const
> std::vector >&, 
> cmExecutionStatus&> (__f=...) at /usr/include/c++/13/bits/invoke.h:61
> #9  std::__invoke_r BuiltinCommand)::&, 
> cmExecutionStatus&)>&, const std::vector std::allocator >&, cmExecutionStatus&> (__fn=...) at 
> /usr/include/c++/13/bits/invoke.h:114
> #10 std::_Function_handler std::allocator >&, cmExecutionStatus&), 
> cmState::AddBuiltinCommand(const std::string&,
> BuiltinCommand):: std::allocator >&, cmExecutionStatus&)> 
> >::_M_invoke(const std::_Any_data &, const std::vector std::allocator > &, cmExecutionStatus &) (__functor=..., 
> __args#0=..., __args#1=...) at /usr/include/c++/13/bits/std_function.h:290
>
> This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said 
> he
> would be looking into it. In case he comes up with a solution, I will report 
> it
> here.
>
> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17=ppc64=1%3A17.0.6-4%2Bb2=1704985815=0
> > [2] https://bugzilla.suse.com/show_bug.cgi?id=1218365

It may be a good idea to give the CMake folks the first chance at the
fix. It does not look like it has been reported to them:
. Searching with
'ppc' and 'llvm' tags returned 0 hits:
.
(Maybe I missed it in their bug tracker).

Jeff

Re: cmake ftbfs on ppc64el (and ppc64)

[John Paul Adrian Glaubitz]

Hello,

the bug is definitely still present and I'm therefore not sure whether
downgrading the priority to normal is justified.

On ppc64, cmake still crashes regularly when configuring the LLVM build
for example [1]:

-- Looking for pow in m - found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Looking for backtrace in execinfo
Segmentation fault

I have performed a local LLVM test build and obtained a backtrace with gdb
which also indicates a crash in libuv:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0x7fff811f6e60 (LWP 2635470))]
(gdb) bt
#0  0x in ?? ()
#1  
#2  0x7fff82eee784 in __GI_epoll_pwait (epfd=4, events=0x7fffd3808cc8, 
maxevents=1024, timeout=-1, set=0x0) at 
../sysdeps/unix/sysv/linux/epoll_pwait.c:40
#3  0x7fff83545238 in uv__io_poll (loop=0x10015e8edd0, timeout=-1) at 
./src/unix/linux.c:1365
#4  0x7fff8352aa84 in uv_run (loop=0x10015e8edd0, mode=UV_RUN_ONCE) at 
./src/unix/core.c:447
#5  0x000132669d8c in cmExecuteProcessCommand (args=..., status=...) at 
./Source/cmExecuteProcessCommand.cxx:358
#6  0x000132561d38 in InvokeBuiltinCommand (status=..., args=..., 
command=@0x133045248: 0x1326682b0 
,
std::allocator >, std::allocator, std::allocator > > > const&, cmExecutionStatus&)>)
at ./Source/cmState.cxx:420
#7  operator() (status=..., args=..., __closure=) at 
./Source/cmState.cxx:430
#8  std::__invoke_impl&, 
cmExecutionStatus&)>&, const
std::vector >&, 
cmExecutionStatus&> (__f=...) at /usr/include/c++/13/bits/invoke.h:61
#9  std::__invoke_r&, 
cmExecutionStatus&)>&, const std::vector >&, cmExecutionStatus&> (__fn=...) at 
/usr/include/c++/13/bits/invoke.h:114
#10 std::_Function_handler >&, cmExecutionStatus&), 
cmState::AddBuiltinCommand(const std::string&,
BuiltinCommand):: >&, cmExecutionStatus&)> >::_M_invoke(const 
std::_Any_data &, const std::vector > &, cmExecutionStatus &) (__functor=..., 
__args#0=..., __args#1=...) at /usr/include/c++/13/bits/std_function.h:290

This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said he
would be looking into it. In case he comes up with a solution, I will report it
here.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17=ppc64=1%3A17.0.6-4%2Bb2=1704985815=0
> [2] https://bugzilla.suse.com/show_bug.cgi?id=1218365

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913