|
Bugzilla – Full Text Bug Listing |
| Summary: | /usr/lib/YaST2/startup/YaST2.call: line 454: 4718 Segmentation fault (core dumped) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Dominik Heidler <dheidler> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED WORKSFORME | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | okurz |
| Version: | Leap 15.5 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
screenshot from serial console
y2logs.tar.xz |
||
Created attachment 868637 [details]
y2logs.tar.xz
Start and end of the y2log of this second stage: 2023-08-04 15:16:41 <1> openqaworker26(4705) [Ruby] bin/y2start(<main>):22 y2base called with ["installation", "--arg", "continue", "ncurses"] ... ... 2023-08-04 15:17:42 <1> openqaworker26(4705) [ncurses] NCurses.cc(~NCurses):145 Shutdown NCurses... 2023-08-04 15:17:42 <1> openqaworker26(4705) [ncurses] NCurses.cc(~NCurses):164 NCurses down 2023-08-04 15:17:42 <1> openqaworker26(4705) [Pkg] PkgFunctions.cc(~PkgFunctions):152 Releasing the repo manager... 2023-08-04 15:17:42 <1> openqaworker26(4705) [Pkg] PkgFunctions.cc(~PkgFunctions):159 Releasing the zypp pointer... 2023-08-04 15:17:42 <1> openqaworker26(4705) [Pkg] PkgFunctions.cc(~PkgFunctions):161 Zypp pointer released That does not indicate a segfault or any other serious problem. Yet in y2start.log, I see for the second stage: Stage [call]: ================ Stage [call]: Starting YaST... Stage [call]: ================ |-- Allow big memory allocation: overcommit_memory=1 |-- MODULE_NAME: installation |-- MODE_FLAGS: |-- MODULE_ARGS: --arg continue |-- MODE: ncurses |-- UI_ARGS: |-- QT_IM_MODULE: xim Stage [call]: =============== Stage [call]: YaST terminated Stage [call]: =============== |-- Y2_EXIT_CODE: 139 |-- YaST procedure ended successfully |-- Reset memory allocation: overcommit_memory=0 |-- Creating hook script list: postSecondCall... Stage [2]: Starting S09-cleanup... Stage [2]: ======================= |-- kill console with PID: 3808 |-- Shutdown SSH daemon and network interfaces... |-- Stopping UTF-8 mode... |-- Creating hook script list: postSecondStage... Notice exit code 139, i.e. 128 + 11, i.e. it terminated with a signal (>127), and the signal was #11, SIGSEGV. % grep 'SIG.*11' /usr/include/asm/signal.h #define SIGSEGV 11 On my machine, I see one more line in the y2log after a regular shutdown of YaST: 2023-08-03 21:27:15 <1> balrog(6329) [Pkg] PkgFunctions.cc(~PkgFunctions):161 Zypp pointer released 2023-08-03 21:27:15 <1> balrog(6329) [Y2Ruby] binary/YRuby.cc(~YRuby):117 Shutting down ruby interpreter. It's hard to say what happens in between those two log lines without a full debug log. And it's unsure if that would give us more information since not every step during program shutdown is logged. We can only guess why it segfaulted at that stage. It might be a shutdown order problem, but those are very hard to track down. But since you didn't observe any bad effects because of this, for the time being let's just take note that this happened at least once. @Dominik I know that you and me saw the issue reproducibly. Can you provide proper "Steps to reproduce", at best an openQA test scenario showing the problem? Since libzypp did not catch the signal and did not log a backtrace, we can only guess that this happened after that part of libzypp was already shut down. But that also doesn't really tell us much. If this is a new problem and somebody feels like spending a lot of time on it, bisecting the changes since the last working version and the first non-working one would be an option; if this were about a nuclear powerplant or some similar life-or-death scenario. But since that is not the case, I don't see a reason to go to such extremes. It does shut down, it gets almost to the regular end; and then there is a segfault which speeds up the shutdown. That's not nice, but it's also not a serious problem. |
Created attachment 868636 [details] screenshot from serial console On 2nd stage yast during 15.5 installation, this error appears on the console. The installation actually seems to be completed fine, as this error only seems to appear after yast finished, what it planned to do. Hardware is a supermicro x86_64 server and console is IPMI sol.