Skip to main content
Topic: wireplumber segmentation fault (Read 546 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

wireplumber segmentation fault

Hi all,

 after the last update of pipewire and related packages 1:0.3.70-1 --> 1:0.3.70-2 wireplumber 0.4.14-1 stopped working due to a segmentation fault.

 Downgrading to 1:0.3.70-1 solved the issue.

 The culprit seems to be libcamera-base.so.0.0.5, is anyone seeing the issue too?

 gdb backtrace:

 Thread 1 "wireplumber" received signal SIGSEGV, Segmentation fault.
0x00007ffff433bf1a in std::basic_ostream<char, std::char_traits<char> >::sentry::sentry (this=0x7fffffffdd90, __os=...)
    at /home/work/src/gcc-obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51
51   /home/work/src/gcc-obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc: No such file or directory.
(gdb) bt
#0  0x00007ffff433bf1a in std::basic_ostream<char, std::char_traits<char> >::sentry::sentry(std::basic_ostream<char, std::char_traits<char> >&)
    (this=0x7fffffffdd90, __os=...) at /home/work/src/gcc-obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51
#1  0x00007ffff433c2a5 in std::basic_ostream<char, std::char_traits<char> >::write(char const*, long)
    (this=0x7ffff44233a0 <std::cerr>, __s=0x5555557ceac0 "[0:21:23.382054051] [9013] \033[1;32m INFO \033[1;37mCamera \033[1;34mcamera_manager.cpp:298 \033[0mlibcamera v0.0.5\n", __n=105) at /home/work/src/gcc-obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:192
#2  0x00007ffff4446428 in libcamera::LogOutput::writeStream(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
    at /usr/lib/libcamera-base.so.0.0.5
#3  0x00007ffff444aa50 in libcamera::LogOutput::write(libcamera::LogMessage const&) () at /usr/lib/libcamera-base.so.0.0.5
#4  0x00007ffff444c092 in libcamera::Logger::write(libcamera::LogMessage const&) () at /usr/lib/libcamera-base.so.0.0.5
#5  0x00007ffff444dc1c in libcamera::LogMessage::~LogMessage() () at /usr/lib/libcamera-base.so.0.0.5
#6  0x00007ffff44c8884 in libcamera::CameraManager::start() () at /usr/lib/libcamera.so.0.0.5
#7  0x00007ffff47af8fa in  () at /usr/lib/spa-0.2/libcamera/libspa-libcamera.so
#8  0x00007ffff47b0c42 in  () at /usr/lib/spa-0.2/libcamera/libspa-libcamera.so
#9  0x00007ffff7f3a5ca in  () at /usr/lib/libwireplumber-0.4.so.0
#10 0x00007ffff7f5f203 in wp_transition_advance () at /usr/lib/libwireplumber-0.4.so.0
#11 0x00007ffff7f43b5a in  () at /usr/lib/libwireplumber-0.4.so.0
#12 0x00007ffff7dc153b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#13 0x00007ffff7e1e219 in  () at /usr/lib/libglib-2.0.so.0
#14 0x00007ffff7dc0c7f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#15 0x00005555555562fd in  ()
#16 0x00007ffff7aa5790 in  () at /usr/lib/libc.so.6
#17 0x00007ffff7aa584a in __libc_start_main () at /usr/lib/libc.so.6
#18 0x00005555555565f5 in  ()

Re: wireplumber segmentation fault

Reply #1
Works fine here.

51   /home/work/src/gcc-obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc: No such file or directory.
(gdb) bt
I think this is your problem. Why on earth is it looking in this directory and not /usr/include?

Re: wireplumber segmentation fault

Reply #2
Works fine here.

51   /home/work/src/gcc-obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc: No such file or directory.
(gdb) bt
I think this is your problem. Why on earth is it looking in this directory and not /usr/include?

This is not a compilation issue. A runtime problem caused by a missing include would be bizzare... ;)

Re: wireplumber segmentation fault

Reply #3
I'm saying that your backtrace makes zero sense. Why is looking for symbols in what is presumably your user directory and not in /usr/include which is where that file actually is?

 

Re: wireplumber segmentation fault

Reply #4
I repeat: This is not a compilation issue.
The compiler and libstdc++.so.6 were built here, so the paths in the bt messages may be misleading.

Re: wireplumber segmentation fault

Reply #5
I repeat: This is not a compilation issue.
The compiler and libstdc++.so.6 were built here
That's an extremely important detail. If you are using your own stdc++ built with who knows what options and not actual Artix packages, then yes it is not inconceivable for something like this to happen. I don't think it's possible for anyone besides yourself to debug this.