| Summary: | kinit: kdeinit crashes with EXC_GUARD on Mac | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kinit | Reporter: | RJVB <rjvbertin> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | kdelibs-bugs, me |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Evidently the old code avoided crashing due to the fact that casting rl.rlim_max (an rlim_t, uint64) led to maxfd < 0 ... Another apparently safe way to avoid this issue: use `fcntl(fd, F_SETFD, FD_CLOEXEC)` instead of `close(fd)`. I *think* that ought to have the same effect? Thank you for reporting this crash in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the crash with a recent software version? If you can reproduce the issue, please change the status when you reply to "CONFIRMED" when replying. Thank you! That's going to be tricky because KInit is a tier-3 fw and I am still blocked on 5.60.0 on my Mac. I'll see if any relevant changes have been made to the code paths involved here, to what extent I can backport them and what difference that makes... RJB, for what it's worth, you can install all the dependencies using Homebrew and compile kinit against them, if needed. Besides being in the MacPorts camp HB still wouldn't allow me to run Qt 5.15 . Why not? Qt5 is at 5.15.5_3 in Homebrew. Because my system doesn't run anything newer than Qt 5.9 Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |
SUMMARY After #26620aef kdeinit5 crashes on startup under Mac OS with an EXC_GUARD exception. STEPS TO REPRODUCE 1. install a kinit version build from code newer than #26620aef 2. start kdeinit5 3. OBSERVED RESULT Under lldb: (lldb) r Process 39953 launched: '/opt/local/bin/kdeinit5' (x86_64) Process 39953 stopped * thread #1: tid = 0xdcc90, 0x00007fff85a560c2 libsystem_kernel.dylib`close + 10, queue = 'com.apple.main-thread', stop reason = EXC_GUARD (code=4611686022722355203, subcode=0x7fff89db7c48) frame #0: 0x00007fff85a560c2 libsystem_kernel.dylib`close + 10 libsystem_kernel.dylib`close + 10: -> 0x7fff85a560c2: jae 0x7fff85a560cc ; close + 20 0x7fff85a560c4: movq %rax, %rdi 0x7fff85a560c7: jmp 0x7fff85a5219a ; cerror 0x7fff85a560cc: retq (lldb) up frame #1: 0x0000000100005c77 kdeinit5`main + 663 at kinit.cpp:175 172 #if KDEINIT_OOM_PROTECT 173 if (fd != oom_pipe) 174 #endif -> 175 close(fd); 176 } 177 } 178 (lldb) p fd (int) $0 = 3 EXPECTED RESULT No crash. SOFTWARE/OS VERSIONS Mac OS X 10.9.5 ADDITIONAL INFORMATION A debug trace added to cleanup_fds() shows: void cleanup_fds() rl.cur/max= 256 / 9223372036854775807 FD_SETSIZE= 1024 According to the debugger the crash happens at the very first close() (i.e. close(3)), and reverting the recent change does fix the issue. About the EXC_GUARD exception: googling shows that this is raised when you try to close a guarded resource, e.g. a file descriptor open in another application or that you shouldn't be closing otherwise. I have NOT found any indication that one can test for this in a non-fatal manner. For now it seems that just excluding fd=3 solves the issue, but ultimately it might be necessary to skip the entire step.