Bug 872182
| Summary: | Process /usr/libexec/xscreensaver/pinion was killed by signal 11 (SIGSEV) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter H. Jones <jones.peter.busi> | ||||||||||
| Component: | mesa | Assignee: | Adam Jackson <ajax> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 16 | CC: | ajax, jan.kratochvil, mtasaka | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2013-02-13 08:26:23 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Peter H. Jones
2012-11-01 13:37:46 UTC
Maybe the coredump for this segv is left under ~/.cache/abrt ? If so, would you take backtrace for this? It wasn't there. Maybe in /var/spool/abrt, but it wasn't obvious. I can look again later. I tried generating a local GNU backtrace, but I could not submit it because the backtrace was unusable. Is it still worthwhile to find the coredump? (In reply to comment #1) > Maybe the coredump for this segv is left under ~/.cache/abrt ? If so, would > you take backtrace for this? Well, actually under ~/.cache/abrt/spool/ccpp-XXXXXXXX/. (In reply to comment #2) > It wasn't there. Maybe in /var/spool/abrt, but it wasn't obvious. I can look > again later. > > I tried generating a local GNU backtrace, but I could not submit it because > the backtrace was unusable. Is it still worthwhile to find the coredump? Unless coredump I cannot figure out what is the cause, so I appreciate it if you can. Created attachment 638647 [details]
compressed tar of core dump archive
The files generated by abrt are in $HOME/.abrt/spool . Here is the tar of all the files in this morning's occurrence. Hope it helps.
Would you take backtrace from coredump by yourself? Currently I have no x86_64 machine available, and even if I get the one, it may be impossible to generate backtrace from your coredump on that machine. (I checked "backtrace" file in the tarball but the generated backtrace was incomplete) Well, now I could access one x86_64 machine, so I tried to get proper backtrace using mock environment, however gdb complains about "No symbol table info available", even if proper debuginfo rpms are installed... Currently I don't know how to debug this... From my yum.log: Nov 06 07:28:29 Installed: kernel-3.6.5-2.fc16.x86_64 Nov 08 07:51:00 Updated: 1:xscreensaver-base-5.20-3.fc16.x86_64 Nov 08 07:51:02 Updated: 1:xscreensaver-extras-base-5.20-3.fc16.x86_64 Nov 08 07:51:02 Updated: 1:xscreensaver-gl-base-5.20-3.fc16.x86_64 Nov 08 07:51:12 Updated: xulrunner-16.0.2-1.fc16.x86_64 Nov 08 07:51:25 Updated: firefox-16.0.2-1.fc16.x86_64 Nov 08 07:51:32 Updated: 1:xscreensaver-gl-extras-5.20-3.fc16.x86_64 Nov 08 07:51:37 Updated: 1:xscreensaver-extras-5.20-3.fc16.x86_64 Since I now have an updated xscreensaver, I propose to wait for a new occurrence before putting more effort in analyzing the dumps I already have. Okay, if this issue reproduces, please let me know it then. Thank you for reporting anyway. Created attachment 646164 [details]
compressed tar of core dump archive
Got the bug again. I have uploaded the compressed tar produced by ABRT. Once again, ABRT says the backtrace is unusable.
Just for sure: * Would you write the result of the below? $ rpm -qf /usr/libexec/xscreensaver/pinion /usr/lib64/libGL.so.1 /usr/lib64/libGLU.so.1 /lib64/libc.so.6 /usr/lib64/libX11.so.6 * Also would you attach /etc/X11/xorg.conf (if this exists) and /var/log/Xorg.0.log ? Created attachment 646335 [details]
Xorg.0.log requested
I have several files with similar names. I am uploading the one that was requested.
And would you show me the result of the commend in my comment 12 for confirmation? Thank you. Oops, in my comment 11, sorry. Oh, it was on dso_list file... I don't have /etc/X11/xorg.conf, just a directory with one file,
/etc/X11/xorg.conf/00-system-setup-keyboard.conf, containing:
# This file is autogenerated by system-setup-keyboard. Any
# modifications will be lost.
Section "InputClass"
Identifier "system-setup-keyboard"
MatchIsKeyboard "on"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbVariant" "intl"
Option "XkbOptions" "terminate:ctrl_alt_bksp,"
EndSection
AFAIK I haven't modified this file.
gdb maintainer, would you have some idea why I cannot generate proper backtrace even if I install debuginfo rpms (which I assume are proper)? Any help is appreciated. The Comment 10 crash is at 0x7f1b361fe460: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x77b000 0x7f1b361fe000 0x000000000000 0x080000 0x080000 RWE 0x1000 maps: 7f1b361f6000-7f1b361fe000 rw-s 10b39a000 00:05 6683 /dev/dri/card0 7f1b361fe000-7f1b3627e000 rwxp 00000000 00:00 0 7f1b3627e000-7f1b3627f000 rw-s 10b399000 00:05 6683 /dev/dri/card0 The address does not belong to any ELF executable there. RWE is unusual on GNU/Linux. And the code looks like some gfx acceleration: (gdb) x/20i $pc => 0x7f1b361fe460: movss (%r15,%rcx,1),%xmm2 0x7f1b361fe466: movss 0x4(%r15,%rcx,1),%xmm3 0x7f1b361fe46d: movss (%r15,%rdi,1),%xmm4 So I believe it is some JIT code, GDB has framework for JIT debugging but I do not whether the drivers provide some features for it. Moreover it is not loaded automatically by GDB so one would need to know what to execute in GDB. Jan, thank you for analysing. Created attachment 648840 [details]
ABRT log file of another occurrence
Judging from Jan's comment, once reassigning to mesa(-dri-drivers) and asking for help. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |