postfix package for pfSense 2.3 #23
Conversation
| break; | ||
| } | ||
| #update /etc/inc/system.inc | ||
| $sys_log_file = '/etc/inc/system.inc'; |
There was a problem hiding this comment.
Packages will never be allowed to touch system files anymore. It's wrong and dangerous
|
How can I change syslog conf to maillogs on 2.3? Is the a function for this? |
|
There is an implementation also on 2.2 for this, as you can see at https://github.com/pfsense/pfsense/blob/master/src/etc/inc/system.inc#L889 |
packages like postfix needs some custom settings to syslog.conf. As it is dangerous to be done by file hacking.(pfsense/FreeBSD-ports#23) I'm sending this code change to improve system.inc tests on package logging config.
|
Why u no merge |
|
Is there a time-line for the postfix package on PfSense 2.3? |
|
+1 .. any timelines guys? |
|
Are there any problems to merge this pull request? |
|
|
|
+1 waiting for this package! |
|
It would be great to get this package back on the list. |
|
I'll add my support as well. It would be nice to see this merged. |
|
I would love to be able to use this too. |
|
This branch appears to have been ready to go for some time, and we're looking for a highly available MTA to deploy. We already use pfSense for our VPN and HAProxy, it'd be great if we could install this package and be done with it. Is it just waiting for approval? Anything we might be able to do to help move it along? Thanks in advance! |
|
Could we please just have a clear statement about whether the intention is to merge this package or not? |
|
This package is ready to branch since december 2015 and still not available in Pfsense. |
|
Please include it in the packages. |
|
+1 |
|
Waiting for approval On Sep 1, 2016 5:34 PM, "spec1re" [email protected] wrote:
|
|
It's been waiting for approval for 9 months - I'm being patient, but I'm also hoping that maybe some of this discussion might spur things along a little bit. 😄 |
|
@rbgarga any chance to make this move forward? |
|
Hi, Thanks |
|
Please merge! |
|
After many internal discussions, we (pfSense developers) decided that we are not bringing an MTA to pfSense again. |
|
what are the reasons for this decision? |
|
All of the pfSense devs have done such a great job with the software that I wouldn't go so far as to say this is a mistake, however, I too would like to know a little bit of the internal reasoning. My thoughts are as such: pfSense is designed a gateway device, on the edge of network. pfSense really doesn't need to be a full MTA, however, it does make perfect logical sense for it to provide relay functions from the internal network out to the Internet. My intention was to set up postfix so that we could block standard email ports and require that everything inside of our network send outgoing mail to the pfSense box. Due to the excellent CARP and XMLRPC Sync, it would provide a fault-tolerant, HA mail relay that could, in theory, trigger alerts if anything suspicious was trying to relay email from within our network. Of course there are many other ways to accomplish this goal, and we have already implemented one of these methods, but it I do believe there is a good case for being able to include this in pfSense. Again, I'm not trying to start an argument - just curious about the reasoning behind the decision. As always, thank you to the developers who contribute to this project. It is of enormous value to many, many people, and is still (and always will be) my go-to firewall. |
|
I am guessing its the usual answer - fear of it being abused by lazy admins who don't follow best practices. Strange though that they allow bind to make it in, when the same thing could result. |
|
All admins are lazy. It's why we choose to be admins. 😆 |
|
Well sad to see the forward of mail options gone :( |
|
The decision you made today will effect PfSense very shortly, please On Wed, Sep 14, 2016 at 7:19 PM, Dennis Neuhaeuser <[email protected]
|
|
I don't speak for the devs, but I will say that I respect their decision. I think it's important to keep in mind that pfSense is a network security device. It's principal purpose is as a firewall. As a firewall, pfSense begins with a certain minimum attack surface, and every added package increases the attack surface. This is particularly true of packages with open ports, most especially those that open ports on the WAN interface. These things need to be restricted to those that are truly necessary, either because of pfSense's location in the network or because they are needed for basic operation of the firewall itself. Something with the complexity of Postfix with an open WAN port creates a huge increase in the attack surface. ClamAV represents another huge increase. And there is no compelling reason for Postfix/ClamAV to be run on the firewall--it can be run elsewhere without capability loss. Some will say "well, let me make the choice!" and I understand the sentiment. But the vast majority of users are not able to properly evaluate the substantial security risk associated with such a choice. They look at the packages distributed as part of pfSense and assume that they are relatively safe. After all, they wouldn't be part of pfSense if the were not safe would they? As leaders of a firewall project, the pfSense devs have a substantial responsibility to those users. This responsibility sometimes means having to step up and make hard decisions. And that's what they have done. You may not agree with the decision, but you should respect it. Btw, ackstorm23 you make a good point about Bind. Although it is now one of the most throughly reviewed pieces of code you can find, It probably isn't something that should be part of pfSense. NSD perhaps, but not bind. :) |
|
There is a big difference between bind and postfix. Bind is a single service while postfix package is a combination of programs (postfix, spamassassin, clamav, amavis, policyd, ...). It also requires changes on core to disable clog. It's too big for something that is definitely not primary function of pfSense software. That is the main reason we decided to decline it. |
|
Sorry but I think this decision is short sighted. This app provides the perfect front door to any internal mail server. If all you want pFSense to be is a firewall then get rid of the other applications too such as routing, snort, web filtering etc etc. I've used pFSense simply because it means I don't need to configure half a dozen boxes, this app forms part of that strategy - the ability to turn pfSense into an MTA is what makes it so powerful - declining this app is a decision that is mystifying. Postfix is only a collection of app's if you choose to do so. If I need to go back to configuring a dozen boxes to achieve what I need then I'm afraid pfsense won't be one of them and I'll stop recommending it to customers. So do us a favour and start being more honest about why some apps are in and some are out - the pfSense team are startting to show the same arrogance in its decisions as some of the bigger 'commercial' players. |
|
I would also, humbly, ask that the devs keep in mind that the original reason pfSense was forked from m0n0wall was because m0n0wall was "just a network security device." pfSense was supposed to be a more feature-rich install, with a slightly larger footprint, but without all the bloat of something like IPCop or ClarkConnect. I still believe in the mission - I just hope that the features that make pfSense such a great and flexible platform aren't removed, one by one, until we're back to m0n0wall. |
|
I have to say that this decision has troubled me. |
|
This has actually led me to an important question, which I hope that the developers are willing to answer openly and honestly: I'm making system design decisions right now for our network. While we hadn't implemented postfix yet, we're getting ready to purchase and deploy some pfSense appliances for use with HAProxy, as well as some other instances for use with Squid proxy, both in HA configurations. We also rely on the OpenVPN module very heavily in our network. Does this decision to remove postfix from future updates indicate a general shift in the direction pfSense is headed? Do you envision removing other "heavy" components in pfSense, to transition into more of a m0n0wall type, single-purpose device? I'm not asking to be critical or express disappointment. I've been pushing hard for our management to purchase pfSense appliances as well as support over the next few months, and I want to ensure that these devices will continue doing what I'm planning to use them for, including updates and support in the future. |
|
Wouldn't waste your breath - the devs are headed down a different path with pFsense now - they've forgotten why it forked from m0n0wall in the first place. Perhaps we need to repeat the process and follow our own path - alas I haven't the time - wish I did. |
|
@SukMeWot I totally concur. This is why have had to migrate to OPNsense recently. |
No PORTEPOCH bump because this port wasn't stable to begin with. * thread #9, name = 'yuzu:CPUThread', stop reason = signal SIGABRT * frame #0: 0x0000000804146a8a libc.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x0000000804146424 libc.so.7`__raise(s=6) at raise.c:52:10 frame #2: 0x00000008040aef19 libc.so.7`abort at abort.c:67:8 frame #3: 0x00000008038f39b9 libcxxrt.so.1`report_failure(err=<unavailable>, thrown_exception=0x00000009d701aa88) at exception.cc:719:5 frame #4: 0x00000008038c34dc libc++.so.1`std::__1::__throw_system_error(ev=11, what_arg="mutex lock failed") at system_error.cpp:287:5 frame #5: 0x00000008038a834d libc++.so.1`std::__1::mutex::lock(this=<unavailable>) at mutex.cpp:35:9 frame #6: 0x0000000000dbb534 yuzu`std::__1::unique_lock<std::__1::mutex>::unique_lock(this=0x00000009c68f1d90, __m=0x0000000805984918) at __mutex_base:119:61 frame #7: 0x000000000136167d yuzu`Service::NVFlinger::NVFlinger::Lock(this=0x000000080c8c6958) at nvflinger.h:90:16 frame #8: 0x00000000014c5ab4 yuzu`Service::VI::IHOSBinderDriver::TransactParcel(this=0x00000009d536e6f8, thread=std::__1::shared_ptr<Kernel::Thread>::element_type @ 0x000000090faedc20 strong=9 weak=2, ctx=0x00000009d536e310, reason=Signal)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)::operator()(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason) const at vi.cpp:554:37 frame #9: 0x00000000014c59f5 yuzu`decltype(__f=0x00000009d536e6f8, __args=nullptr, __args=0x00000009d536e310, __args=0x00000009c68f2004)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)&>(fp)(std::__1::forward<std::__1::shared_ptr<Kernel::Thread> >(fp0), std::__1::forward<Kernel::HLERequestContext&>(fp0), std::__1::forward<Kernel::ThreadWakeupReason>(fp0))) std::__1::__invoke<Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)&, std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason>(Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)&, std::__1::shared_ptr<Kernel::Thread>&&, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason&&) at type_traits:3539:1 frame #10: 0x00000000014c594c yuzu`void std::__1::__invoke_void_return_wrapper<void>::__call<Service::VI::IHOSBinderDriver::TransactParcel(__args=0x00000009d536e6f8, __args=nullptr, __args=0x00000009d536e310, __args=0x00000009c68f2004)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)&, std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason>(Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)&, std::__1::shared_ptr<Kernel::Thread>&&, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason&&) at __functional_base:348:9 frame #11: 0x00000000014c58dc yuzu`std::__1::__function::__alloc_func<Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason), std::__1::allocator<Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>, void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>::operator(this=0x00000009d536e6f8, __arg=nullptr, __arg=0x00000009d536e310, __arg=0x00000009c68f2004)(std::__1::shared_ptr<Kernel::Thread>&&, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason&&) at functional:1540:16 frame #12: 0x00000000014c480d yuzu`std::__1::__function::__func<Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason), std::__1::allocator<Service::VI::IHOSBinderDriver::TransactParcel(Kernel::HLERequestContext&)::'lambda'(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>, void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>::operator(this=0x00000009d536e6f0, __arg=nullptr, __arg=0x00000009d536e310, __arg=0x00000009c68f2004)(std::__1::shared_ptr<Kernel::Thread>&&, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason&&) at functional:1714:12 frame #13: 0x0000000001116862 yuzu`std::__1::__function::__value_func<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>::operator(this=0x00000009d536e6f0, __args=nullptr, __args=0x00000009d536e310, __args=0x00000009c68f2004)(std::__1::shared_ptr<Kernel::Thread>&&, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason&&) const at functional:1867:16 frame #14: 0x00000000011167bc yuzu`std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>::operator(this= Lambda in File vi.cpp at Line 552, __arg=<unavailable>, __arg=0x00000009d536e310, __arg=Signal)(std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason) const at functional:2473:12 frame #15: 0x000000000110a6a4 yuzu`Kernel::HLERequestContext::SleepClientThread(this=0x00000009d536e310, thread=std::__1::shared_ptr<Kernel::Thread>::element_type @ 0x000000090faedc20 strong=9 weak=2)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0::operator()(std::__1::shared_ptr<Kernel::Thread>) at hle_ipc.cpp:67:17 frame #16: 0x000000000110a5b1 yuzu`decltype(__f=0x00000009d536e310, __args=nullptr)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0&>(fp)(std::__1::forward<std::__1::shared_ptr<Kernel::Thread> >(fp0))) std::__1::__invoke<Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0&, std::__1::shared_ptr<Kernel::Thread> >(Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0&, std::__1::shared_ptr<Kernel::Thread>&&) at type_traits:3539:1 frame #17: 0x000000000110a532 yuzu`bool std::__1::__invoke_void_return_wrapper<bool>::__call<Kernel::HLERequestContext::SleepClientThread(__args=0x00000009d536e310, __args=nullptr)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0&, std::__1::shared_ptr<Kernel::Thread> >(Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0&, std::__1::shared_ptr<Kernel::Thread>&&) at __functional_base:317:16 frame #18: 0x000000000110a4f2 yuzu`std::__1::__function::__alloc_func<Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0, std::__1::allocator<Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0>, bool (std::__1::shared_ptr<Kernel::Thread>)>::operator(this=0x00000009d536e310, __arg=nullptr)(std::__1::shared_ptr<Kernel::Thread>&&) at functional:1540:16 frame #19: 0x00000000011094b3 yuzu`std::__1::__function::__func<Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0, std::__1::allocator<Kernel::HLERequestContext::SleepClientThread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, std::__1::function<void (std::__1::shared_ptr<Kernel::Thread>, Kernel::HLERequestContext&, Kernel::ThreadWakeupReason)>&&, std::__1::shared_ptr<Kernel::WritableEvent>)::$_0>, bool (std::__1::shared_ptr<Kernel::Thread>)>::operator(this=0x00000009d536e300, __arg=nullptr)(std::__1::shared_ptr<Kernel::Thread>&&) at functional:1714:12 frame #20: 0x00000000011834ed yuzu`std::__1::__function::__value_func<bool (std::__1::shared_ptr<Kernel::Thread>)>::operator(this=0x000000090faee1c0, __args=nullptr)(std::__1::shared_ptr<Kernel::Thread>&&) const at functional:1867:16 frame #21: 0x0000000001180c18 yuzu`std::__1::function<bool (std::__1::shared_ptr<Kernel::Thread>)>::operator(this=0x000000090faee1c0, __arg=<unavailable>)(std::__1::shared_ptr<Kernel::Thread>) const at functional:2473:12 frame #22: 0x000000000117edb2 yuzu`Kernel::Thread::InvokeHLECallback(this=0x000000090faedc20, thread=nullptr) at thread.cpp:403:12 frame #23: 0x00000000011929d7 yuzu`Kernel::Svc::SendSyncRequest(system=0x000000000252f3d8, handle=622615) at svc.cpp:365:17 frame #24: 0x000000000118b3b5 yuzu`void Kernel::SvcWrap64<&(Kernel::Svc::SendSyncRequest(Core::System&, unsigned int))>(system=0x000000000252f3d8) at svc_wrap.h:50:24 frame #25: 0x000000000118a334 yuzu`Kernel::Svc::Call(system=0x000000000252f3d8, immediate=33) at svc.cpp:2649:13 frame #26: 0x00000000011a60e3 yuzu`Core::DynarmicCallbacks64::CallSVC(this=0x00000009c657df60, swi=33) at arm_dynarmic_64.cpp:123:9 frame #27: 0x00000000023f2c74 yuzu`Dynarmic::Backend::X64::impl::ThunkBuilder<void (Dynarmic::A64::UserCallbacks::*)(unsigned int), &(Dynarmic::A64::UserCallbacks::CallSVC(unsigned int))>::Thunk(this_=0x00000009c657df60, args=33) at devirtualize.h:28:16
* thread #1, name = 'xdg-desktop-port', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) frame #0: 0x000000000026acf0 xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(data=0x0000000000000000, feedback=0x0000182398a105c0, device_arr=0x0000182398a891d0) at PortalManager.cpp:90:5 87 static void dmabufFeedbackMainDevice(void* data, zwp_linux_dmabuf_feedback_v1* feedback, wl_array* device_arr) { 88 Debug::log(LOG, "[core] dmabufFeedbackMainDevice"); 89 -> 90 RASSERT(!g_pPortalManager->m_sWaylandConnection.gbm, "double dmabuf feedback"); 91 92 dev_t device; 93 assert(device_arr->size == sizeof(device)); (lldb) bt * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) * frame #0: 0x000000000026acf0 xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(data=0x0000000000000000, feedback=0x0000182398a105c0, device_arr=0x0000182398a891d0) at PortalManager.cpp:90:5 frame #1: 0x000000082c61067a libffi.so.8`ffi_call_unix64 at unix64.S:104 frame #2: 0x000000082c60f8f9 libffi.so.8`ffi_call_int(cif=0x0000000820fbba80, fn=(xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(void*, zwp_linux_dmabuf_feedback_v1*, wl_array*) at PortalManager.cpp:87), rvalue=0x0000000000000000, avalue=0x0000000820fbbab0, closure=0x0000000000000000) at ffi64.c:673:3 frame #3: 0x000000082c60f452 libffi.so.8`ffi_call(cif=0x0000000820fbba80, fn=(xdg-desktop-portal-hyprland`dmabufFeedbackMainDevice(void*, zwp_linux_dmabuf_feedback_v1*, wl_array*) at PortalManager.cpp:87), rvalue=0x0000000000000000, avalue=0x0000000820fbbab0) at ffi64.c:710:3 frame #4: 0x00000008242fac28 libwayland-client.so.0`wl_closure_invoke(closure=0x0000182398a89100, flags=1, target=0x0000182398a105c0, opcode=2, data=0x0000000000000000) at connection.c:1025:2 frame #5: 0x00000008242f84cf libwayland-client.so.0`dispatch_event(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1631:3 frame #6: 0x00000008242f72f4 libwayland-client.so.0`dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1777:3 frame #7: 0x00000008242f70bd libwayland-client.so.0`wl_display_dispatch_queue_pending(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:2019:8 frame #8: 0x00000008242f6c8e libwayland-client.so.0`wl_display_dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1995:9 frame #9: 0x00000008242f6814 libwayland-client.so.0`wl_display_roundtrip_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1403:9 frame #10: 0x00000008242f6ce0 libwayland-client.so.0`wl_display_roundtrip(display=0x0000182398a1b140) at wayland-client.c:1432:9 frame #11: 0x0000000000326718 xdg-desktop-portal-hyprland`CToplevelManager::activate(this=0x0000182398a19240) at ToplevelManager.cpp:109:5 frame #12: 0x0000000000267b72 xdg-desktop-portal-hyprland`CPortalManager::onGlobal(this=0x0000182398a1b000, data=0x0000000000000000, registry=0x0000182398a10440, name=24, interface="zwlr_foreign_toplevel_manager_v1", version=3) at PortalManager.cpp:261:34 frame #13: 0x00000000002675e5 xdg-desktop-portal-hyprland`handleGlobal(data=0x0000000000000000, registry=0x0000182398a10440, name=24, interface="zwlr_foreign_toplevel_manager_v1", version=3) at PortalManager.cpp:20:23 frame #14: 0x000000082c61067a libffi.so.8`ffi_call_unix64 at unix64.S:104 frame #15: 0x000000082c60f8f9 libffi.so.8`ffi_call_int(cif=0x0000000820fbc140, fn=(xdg-desktop-portal-hyprland`handleGlobal(void*, wl_registry*, unsigned int, char const*, unsigned int) at PortalManager.cpp:19), rvalue=0x0000000000000000, avalue=0x0000000820fbc170, closure=0x0000000000000000) at ffi64.c:673:3 frame #16: 0x000000082c60f452 libffi.so.8`ffi_call(cif=0x0000000820fbc140, fn=(xdg-desktop-portal-hyprland`handleGlobal(void*, wl_registry*, unsigned int, char const*, unsigned int) at PortalManager.cpp:19), rvalue=0x0000000000000000, avalue=0x0000000820fbc170) at ffi64.c:710:3 frame #17: 0x00000008242fac28 libwayland-client.so.0`wl_closure_invoke(closure=0x0000182398a1b8c0, flags=1, target=0x0000182398a10440, opcode=0, data=0x0000000000000000) at connection.c:1025:2 frame #18: 0x00000008242f84cf libwayland-client.so.0`dispatch_event(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1631:3 frame #19: 0x00000008242f72f4 libwayland-client.so.0`dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1777:3 frame #20: 0x00000008242f70bd libwayland-client.so.0`wl_display_dispatch_queue_pending(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:2019:8 frame #21: 0x00000008242f6c8e libwayland-client.so.0`wl_display_dispatch_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1995:9 frame #22: 0x00000008242f6814 libwayland-client.so.0`wl_display_roundtrip_queue(display=0x0000182398a1b140, queue=0x0000182398a1b230) at wayland-client.c:1403:9 frame #23: 0x00000008242f6ce0 libwayland-client.so.0`wl_display_roundtrip(display=0x0000182398a1b140) at wayland-client.c:1432:9 frame #24: 0x00000000002689a4 xdg-desktop-portal-hyprland`CPortalManager::init(this=0x0000182398a1b000) at PortalManager.cpp:312:5 frame #25: 0x00000000002a3f76 xdg-desktop-portal-hyprland`main(argc=1, argv=0x0000000820fbc870, envp=0x0000000820fbc880) at main.cpp:38:23 frame #26: 0x000000082a0172aa libc.so.7`__libc_start1(argc=1, argv=0x0000000820fbc870, env=0x0000000820fbc880, cleanup=<unavailable>, mainX=(xdg-desktop-portal-hyprland`main at main.cpp:15)) at libc_start1.c:157:7 frame #27: 0x0000000000267520 xdg-desktop-portal-hyprland`_start at crt1_s.S:83 * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGILL: privileged opcode frame #0: 0x0000000824c5f7cf libc++.so.1`std::__1::mutex::unlock(this=<unavailable>) at mutex.cpp:39:3 36 void mutex::unlock() noexcept { 37 int ec = __libcpp_mutex_unlock(&__m_); 38 (void)ec; -> 39 _LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL( 40 ec == 0, "call to mutex::unlock failed. A possible reason is that the mutex wasn't locked"); 41 } 42 (lldb) bt * thread #1, name = 'xdg-desktop-port', stop reason = signal SIGILL: privileged opcode * frame #0: 0x0000000824c5f7cf libc++.so.1`std::__1::mutex::unlock(this=<unavailable>) at mutex.cpp:39:3 frame #1: 0x00000000002691d3 xdg-desktop-portal-hyprland`CPortalManager::startEventLoop(this=0x000021aa1001b000) at PortalManager.cpp:424:48 frame #2: 0x0000000000268f06 xdg-desktop-portal-hyprland`CPortalManager::init(this=0x000021aa1001b000) at PortalManager.cpp:335:5 frame #3: 0x00000000002a3f56 xdg-desktop-portal-hyprland`main(argc=1, argv=0x0000000820d386c8, envp=0x0000000820d386d8) at main.cpp:38:23 frame #4: 0x00000008274222aa libc.so.7`__libc_start1(argc=1, argv=0x0000000820d386c8, env=0x0000000820d386d8, cleanup=<unavailable>, mainX=(xdg-desktop-portal-hyprland`main at main.cpp:15)) at libc_start1.c:157:7 frame #5: 0x0000000000267520 xdg-desktop-portal-hyprland`_start at crt1_s.S:83 (lldb) f 1 frame #1: 0x00000000002691d3 xdg-desktop-portal-hyprland`CPortalManager::startEventLoop(this=0x000021aa1001b000) at PortalManager.cpp:424:48 421 422 while (1) { // dbus events 423 // wait for being awakened -> 424 m_sEventLoopInternals.loopRequestMutex.unlock(); // unlock, we are ready to take events 425 426 std::unique_lock lk(m_sEventLoopInternals.loopMutex); 427 if (m_sEventLoopInternals.shouldProcess == false) // avoid a lock if a thread managed to request something already since we .unlock()ed PR: 278496 Reported by: shurd
No description provided.